Internet DRAFT - draft-heinanen-dirldp-eth-vpns
draft-heinanen-dirldp-eth-vpns
Internet Engineering Task Force Juha Heinanen
INTERNET DRAFT Song Networks
Expires May 2002 November, 2001
Directory/LDP Based Ethernet VPNs
<draft-heinanen-dirldp-eth-vpns-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes how provider based Ethernet VPNs can be
implemented using a directory (such as DNS) and LDP for PE discovery
and label distribution.
1. Introduction
This memo describes a simple mechanism to implement provider based
bridged Ethernet VPNs using a directory and LDP [1] for PE discovery
and label distribution. The directory can be anything where the IP
addresses of the PE routers of a VPN can be stored and queried from.
In this memo we have chosen to use DSN directory as proposed in [2].
An advantage of a directory/LDP based solution for provider based
VPNs is that it doesn't require BGP implementation or configuration
complexity in the PE routers and can be easily deployed also in
inter-AS cases where the VPN sites are attached to PEs in more than
Heinanen Directory/LDP Based Ethernet VPNs [Page 1]
INTERNET DRAFT October, 2001
one AS. The choice of DNS for the directory is justified because it
is already in wide use and can be deployed without any new
standardization effort.
Similar DNS/LDP based solution can also be applied to provider based
Virtual Circuit and Virtual Router VPNs. If there is sufficient
interest, the details will be specified in later memos.
2. Addition of Sites
2.1 Configuration Actions
DNS/LDP based Ethernet VPNs are very easy to provision. Only the
following two configuration actions are needed when a new site (CE
device) is added to a VPN:
(1) If the PE device (PE for short) does not previously connect any
sites of this VPN, the IP address of the PE is configured to
DNS under domain name
vpn-number.as-number.domain
where "vpn-number" and "as-number" are components of the VPN ID
(Route Distinguisher [3]) of the VPN and "domain" is the domain
of the administrative "owner", (e.g., an ISP) of the VPN.
(2) The port of the PE to which the site is connected to is
configured to belong to the VPN. This is done by specifying
the domain, type, and VPN ID of the VPN.
This document covers the case where the type of the VPN is
"Ethernet".
Note that also in the case of a multi-provider VPN, the
administrative "owner" of any VPN is the single body that operates
the master DNS server for the VPN zone. The "owner" of a VPN MAY
choose to make all updates to the zone data of the VPN itself or MAY
allow other providers to dynamically update the zone data. In the
latter case, the use of secure dynamic updates [4] is recommended.
2.2 Protocol Actions
After the above configuration actions, the following protocol actions
take place in sequence at the PE of the new site if the PE of the new
site doesn't previously connect site(s) of the VPN:
(1) The PE of the new site checks that its own IP address has
become available in the DNS.
Heinanen Directory/LDP Based Ethernet VPNs [Page 2]
INTERNET DRAFT October, 2001
(2) The PE of the new site queries DNS for IP addresses of the
other (remote) PEs of the VPN.
(3) The PE of the new site establishes an LDP session with each of
the remote PEs unless one already exists.
(4) The PE of the new site sends a Label Mapping Message to each of
the remote PEs that advertises a label to be used when a remote
PE sends packets to the sites of the VPN at the PE of the new
site. Each such label MUST uniquely identify at the PE of the
new site both the VPN and the sending PE.
The Label Mapping Message uses the following VPN FEC TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN ID TLV | Address Family |VPN ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 octet VPN Identifier (Route Distinguisher) |
+ from RFC 2547 [3] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Element type name: VPN
Type: TBD by IANA
Address Family: set to zero
VPN ID Length: 8 octets
The following protocol actions take place in sequence at a PE when it
receives a Label Mapping message from another PE:
(1) The PE checks from the DNS that the other PE belongs to the
VPN of the Label Mapping Message and that it itself has at
least one site in that VPN. If not, the PE responds to the
Label Mapping Message with a Label Release Message and no other
protocol actions take place at the PE.
(2) The PE checks if it already has a label for the VPN and PE of
the Label Mapping Message. If so, the PE responds to the Label
Mapping Message with a Label Release Message and no other
protocol actions take place at the PE.
(3) The PE checks if it already has itself advertised a label to
the other PE for the VPN of the Label Mapping Message. If not,
the PE sends a Label Mapping Message to the other PE to be used
when the other PE sends packets to the sites of the VPN at the
PE. The advertised label MUST again uniquely identify at the PE
Heinanen Directory/LDP Based Ethernet VPNs [Page 3]
INTERNET DRAFT October, 2001
both the VPN and the other PE.
If the PE of the new site already connects site(s) of this VPN, no
protocol actions take place at either the PE of the new site or at
the remote PEs.
3. Removal of Sites
3.1 Configuration Actions
The following configuration actions are needed when an existing site
(CE device) is removed from a VPN:
(1) If the site to be removed is the last site of the VPN at the
PE, the IP address of the PE is removed from DNS.
(2) The site is removed from the VPN by unconfiguring the VPN from
the port of the PE to which the site is connected to.
3.2 Protocol Actions
After the above configuration actions, the following protocol actions
take place at the PE of the removed site:
(1) If the removed site was the last site of the VPN at the PE, the
PE checks that its IP address does not anymore exist in the DNS
under the zone of the VPN.
(2) The PE removes any existing labels of the VPN that it had
advertised to the remote PEs by sending them a Label Withdraw
Message.
In addition to processing the Label Withdraw Message, the following
protocol actions take place when a PE receives a Label Withdraw
Message from another PE:
(1) The PE removes the label that it had advertised to the other PE
for the VPN of the Label Withdraw Message by sending it a Label
Withdraw Message.
(2) If there is no remaining need to keep the LDP session up
between the PE and the other PE, the PE MAY terminate the LDP
session with the other PE.
4. Failure Recovery
If a PE looses its LDP session with another PE having site(s) in a
common VPN, the PE releases the label it has advertised to the other
Heinanen Directory/LDP Based Ethernet VPNs [Page 4]
INTERNET DRAFT October, 2001
PE for this VPN. The PE then tries to re-establish the LDP session
until (a) the session gets established or (b) this PE or the other PE
no longer have site(s) in this VPN. Once the LDP session gets
established, the PE advertises to the other PE a label to be used to
send packets to the site(s) of the VPN at this PE as described in
section 2.2.
When a PE recovers from a crash, it adds each of the configured VPN
site(s) to their respective VPN(s) as described in section 2.2.
5. Exponential Back-off Behavior
If any protocol action does not succeed immediately, the normal
behavior is that the PE keeps on trying with exponential back-off
until the action either succeeds or becomes invalid due to a change
in VPN configuration. If the protocol action fails for an
implementation specific prolonged period of time, the PE SHOULD
notify the VPN provider about the problem via a management action.
6. Data Plane
The PEs that host the sites of a VPN act as fully connected learning
bridges. When PE A needs to forward an Ethernet packet to PE B, PE A
prefixes the Ethernet packet by a label stack entry [5] holding the
label that PE B has advertised to PE A for this VPN. PE A then sends
the resulting frame to PE B in any available tunnel, such as a HIP,
GRE, IPSec, VLAN, or MPLS.
How a PE decides, which tunneling protocol to use to send labeled
packets to another PE, is outside the scope of this memo. Usually
the PE would try tunneling protocols in its own preferred order until
the tunnel gets established. In most cases the availability of a
tunneling protocol can be determined by out-of-band means (e.g., DNS
in case of HIP and IPSec, existence of an outer tunnel in case of
MPLS, or existence of a shared authentication key in case of GRE).
7. DNS Zone Update Latency
In order to make addition and removal of VPN PEs as fast as possible,
it is important to try to minimize the latency of VPN zone updates.
This can be achieved by turning on DNS NOTIFY [6] in the master
server for each VPN zone and/or by configuring zone refresh times
small.
8. DNS Message Size
Correct operation of directory/LDP based VPNs requires that IP
addresses of all PE routers of a VPN fit into a single DNS response.
Heinanen Directory/LDP Based Ethernet VPNs [Page 5]
INTERNET DRAFT October, 2001
In order to be able to support large VPNs with a large number of PEs,
the message size requirements of [7] also apply to DNS servers and
resolvers used for implementing the mechanism of this memo.
Fulfilling those requirements allows provisioning of DNS/LDP based
VPNs that consist of a few hundred of PEs, which is envisioned to be
more than adequate for Ethernet VPNs.
9. Security Considerations
Security of directory/LDP based VPNs depends on security of the
directory (DNS), LDP, and the tunneling protocol(s). Security of LDP
is covered in the security section of [1]. Also the various
tunneling protocol specifications have their own security sections.
Regarding DNS security, the important issues related to this memo are
security of zone transfers, security of dynamic updates, as well as
integrity and authentication of DNS queries and responses. Dynamic
updates were already discussed in section 2.1 with a recommendation
to use secure dynamic updates [4]. Security of zone transfers and
integrity of queries and responses are addressed by DNS extensions
[8] and [9].
No DNS extensions exist for providing confidentiality for queries or
responses. It is thus possible that if a party knows the VPN ID of a
VPN and the zone that hosts it, the party can find out the IP
addresses of PE routers that connect sites of that domain. Depending
on the situation, that may or may not be an acceptable security risk.
In a single-provider VPN, the DNS servers that host the VPN
information can be easily fire-walled from all public access. Another
way to prevent outside parties from accessing VPN information is to
use DNS access lists that allow VPN zone related queries only from
trusted PE routers.
See [2] for additional DNS/VPN related security discussion.
Acknowledgements
I would like to thank Joel Halpern of Longitude Systems and Matt
Squire of Hatteras Networks for their constructive comments on an
earlier versions of this memo.
References
[1] Andersson, et al., "LDP Specification". RFC 3036, January 2001.
[2] Luciani et al., "Using DNS for VPN Discovery". draft-luciani-
ppvpn-vpn-discovery-00.txt, September 2001.
Heinanen Directory/LDP Based Ethernet VPNs [Page 6]
INTERNET DRAFT October, 2001
[3] Rosen and Rekhter, "BGP/MPLS VPNs". RFC 2547, March 1999.
[4] Wellington, "Secure Domain Name System (DNS) Dynamic Update".
RFC 3007, November 2000.
[5] Rosen et al., "MPLS Label Stack Encoding". RFC 3032, January
2001.
[6] Vixie, "A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)". RFC 1996, August 1996.
[7] Gudmundsson, "DNSSEC and IPv6 A6 aware server/resolver message
size requirements". draft-ietf-dnsext-message-size-04.txt, February
2001.
[8] Vixie, et al., "Secret Key Transaction Authentication for DNS
(TSIG)". RFC 2845, May 2000.
[9] Eastlake, "Domain Name System Security Extensions". RFC 2535,
March 1999.
Author's Address
Juha Heinanen
Song Networks, Inc.
Hallituskatu 16
33200 Tampere, Finland
Email: jh@song.fi
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Heinanen Directory/LDP Based Ethernet VPNs [Page 7]
INTERNET DRAFT October, 2001
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Heinanen Directory/LDP Based Ethernet VPNs [Page 8]
