One document matched: draft-pegrum-vmmt-00.txt
Network Working Group S. Pegrum
Internet Draft D. Jamieson
Expiration Date: September 1998 M. Yuen
Nortel (Northern Telecom) Ltd.
March 1998
VPN Multipoint to Multipoint Tunnel Protocol (VMMT)
draft-pegrum-vmmt-00.txt
Status of this Memo
This document is an Internet-Draft. 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''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast)
Abstract
For many carrier's, the implementation of Virtual Private Network
(VPN) services using current IP Tunneling technology is problematic
because of onerous configuration requirements. The VMMT is an
protocol for the dynammic distribution of VPN information throughout
a shared network, and the automatic formation of multi-point to
multi-point tunnels between VPN routers.
The method described in this internet draft is intended for single
AS where the AS administrator is a trusted third party. Traffic
seperation is maintained between VPNs.
Table of Contents
1 Introduction ............................................ 2
1.1 Terminology ............................................. 2
2 Address Assignment ...................................... 2
3 Routing Updates ......................................... 3
4 Message Formats ......................................... 4
5 VPN Configuration Information Distribution .............. 6
Pegrum, et. al. Internet Draft [Page 1]
RFC NNNN VMMT Protocol March 1998
5.1 Multicast Enabled Shared Networks .......................
6 5.2 Non-Multicast Enabled Shared Networks ...................
6 6 Summary .................................................
6 7 Security Considerations .................................
7 8 Referneces ..............................................
7 9 Author's Address ........................................
7
1. Introduction
For the purposes of this document, a VPN shall be considered to
consist of a grouping of private routers that use a shared tunneled
backbone. Multiple VPNs use the shared backbone.
Private routers that are members of the same VPN form a peer group.
The members of the peer group communicate with each other over a
logical shared broadcast medium which is actually the tunnelled
backbone simulating a shared broadcast medium for each VPN peer
group.
In common tunnel implementations, tunnels are point to point
connections where the endpoints are statically configured by the
network operator. The VMMT protocol dynamically distributes
connection information (tunnel endpoints) between VPN peers
throughout a shared network, to allow dynamic establishment of a
tunnel. The VPN connection information could include multi-cast
information allowing the establishment of multi-point to multi-point
tunnels.
Each VPN peer (router) belonging to a VPN is identified by a 32 bit
VPN identifier (VPNID) that is unique in the shared network, but
common to all routers belonging to the VPN.
2. Address Assignment
Each VPN peer would have assigned to it one shared IP address and
multiple private IP addresses. The shared IP address is used as the
source address in all tunnel IP headers. There is also, optionally, a
shared IP multi-cast group address which is used to send VPN
multicast or broadcast packets to VPN peers . It also has one
private address for each interface into the private network, and one
for the interface into the shared network. The private IP address
for the interface into the shared network will have the same IP
subnet value as all VPN peers.
3. Routing Updates
Pegrum, et. al. Internet Draft [Page 2]
RFC NNNN VMMT Protocol March 1998
No routing information is exchange between the shared and private
networks. Routing updates from the shared network are blocked and
not transmitted into the private networks. Conversely, private
network updates, even though they are tunnelled across the shared
network, are not transmitted into the shared network.
Pegrum, et. al. Internet Draft [Page 3]
RFC NNNN VMMT Protocol March 1998
4. Message Formats
The message formats follow standard ICMP type messages. The IP
Header is not shown in the diagrams below.
VPN ICMP Solicitation Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs | Addr Entry Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
IP Header Addresses:
Destination Address: Shared Network IP Address
Source Address: Shared Network IP Address
ICMP Fields:
Type: VPN Solicitation Type
Code: 0
Checksum: 16 bit one's complement of entire message
Num VPNs: Number of VPNs contained in this message
Addr Entry: Size of message in 32 bit words
Pegrum, et. al. Internet Draft [Page 4]
RFC NNNN VMMT Protocol March 1998
VPN ICMP Advertisement Message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs | Addr Entry Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
Shared Network IP Fields:
Destination Address: Shared Network IP Address
Source Address: Shared Network IP Address
ICMP Fields:
Type: VPN Solicitation Type
Code: 0
Checksum: 16 bit one's complement of entire message
Num VPNs: Number of VPNs contained in this message
Addr Entry: Size of message in 32 bit words
Pegrum, et. al. Internet Draft [Page 5]
RFC NNNN VMMT Protocol March 1998
5. VPN Configuration Information Distribution
5.1 Multicast Enabled Shared Networks
Each VPN peer is required to join the multicast group that is
provisioned for its associated VPN. After joining the multicast
group, the VPN peer then executes an ICMP Router Discovery [1] like
protocol on that multicast group. These messages are a combination of
VPN discovery and address resolution. The VPN discovery is meant to
be a security measure to ensure that all routers belonging to this
multi-cast group belong to the same VPN. This is intended to guard
against configuration errors only. It is assumed that the shared
network is secure.
New VPN peers joining the multi-cast group immediately issue a VPN
ICMP Router Solicitation message to trigger advertisements from other
routers on the VPN. This provides immediate configuration feedback to
the network operator upon switch reconfiguration, by allowing the VPN
peer to compare the VPNID advertised with it's own. In addition, each
switch periodically issues a VPN Router Advertisement Message to
ensure that the VPN integrity is maintained. The default period for
Advertisement Messages is every 10 minutes but the network operator
can configure the advertisement rate as appropriate for the network.
The VPN peers are now able to communicate with one another through
standard routing protocols. VPN broadcast messages traverse shared
network as a multicast address so that only entities belonging to
that VPN see those messages. ARP entries on VPN peers are refreshed
when processing the VPN ICMP Advertisement messages received from
other peers. The private address resolves into a shared network
unicast address. Unicast VPN messages traverse the shared network as
unicast tunnelled messages.
5.2 Non-Multicast Enabled Shared Networks
The VMMT distribution mechanism is the same as in the multi-cast
enabled case except that the shared destination address is a
broadcast address instead of a multicast group address.
6. Summary
VMMT addresses several problems:
- Dynamic VPN endpoint configuration
- Multi-point to Multi-point tunnels.
- Security against network operator misconfiguration
- Ensures network isolation
Pegrum, et. al. Internet Draft [Page 6]
RFC NNNN VMMT Protocol March 1998
The VMMT protocol allows for scalable VPN solutions using a common
shared infrastructure.
7. Security Considerations
This protocol requires the shared network to be secure and trusted.
8. References
[1] S. Deering, Editor, "ICMP Router Discovery Messages", RFC 1256,
Xerox PARC, September 1991 [2] S. Hanks et al., "Generic Router
Encapsulation", RFC 1701, NetSmiths Ltd & Cisco Systems, October
1994
9. Author's Address
Scott Pegrum
Nortel (Northern Telecom), Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: spegrum@Nortel.ca
Dwieght Jamieson
Nortel (Northern Telecom), Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: djamies@Nortel.ca
Matthew Yuen
Nortel (Northern Telecom), Ltd.
PO Box 3511 Station C
Ottawa ON K1Y 4H7
Canada
EMail: myuen@Nortel.ca
Pegrum, et. al. Internet Draft [Page 7]
--------------------------------------------------------------------------
Scott Pegrum
Nortel Enterprise Networks
Phone: (613) 763-2693
Fax: (613) 765-2186
email: spegrum@nortel.ca
| PAFTECH AB 2003-2026 | 2026-04-22 18:37:54 |