Draft: draft-ietf-l3vpn-bgp-ipv6-06.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Monday 7/25/2005 2:42 PM CST LC Date: 22 June 2005 Summary: Summary - this document is on the right track for publication as Proposed Standard, but there is still some work to do. Review: -------- My notes follow, prefixed by "Spencer -". Spencer Dawkins 1. Introduction A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively the same logical interface may be used for both IPv4 and IPv6 in which case a per-packet lookup at the Version field of the IP packet header determines the IP version. This document only concerns itself with handling of the IPv6 packets. As such the inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. Spencer - the previous paragraph seemed to be talking about interaction between IPv4 and IPv6 at a single site. If this is equivalent to interaction betwen an IPv4 site and an IPV6 site, it's confusing. It's not equivalent, I don't undertand how this paragraph ties to the previous paragraph. In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs as well as over other tunneling techniques including GRE tunnels, IP-in-IP tunnels, L2TPv3 tunnels and IPsec protected tunnels. Spencer - The two "includings" list the same set of tunneling techniques in the same order, but the reader needs to work pretty hard to figure out that the lists are the same, and one list has references while the other does not. Maybe just end the last sentence at "other tunneling techniques"? o where both IPv4 VPNs and IPv6 VPN services are supported over an IPv4 core, the same single set of MP-BGP peering relationships and the same single PE-PE tunnel mesh MAY be used for both; Spencer: Is the same statement true for services over an IPv6 core? Either way, it would be clearer to say so. 2. The VPN-IPv6 Address Family A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte "Route Distinguisher" (RD) and ending with a 16-byte IPv6 address. If two VPNs use the same IPv6 address prefix (effectively denoting different physical systems), the PEs translate these into unique VPN-IPv6 address prefixes using different RDs. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN. Spencer: I'm not the NAT police, but this paragraph seems to accommodate widespread use of private addresses in IPv6, and I didn't think we talked about unroutable IPv6 addresses in standards-track documents - but this is a good AD question, of course. The purpose of the RD is solely to allow one to create distinct routes to a common IPv6 address prefix, similarly to the purpose of the RD defined in [2547bis]. As it is possible per [2547bis], the RD "Since this is possible"? the sentence was just difficult to parse. can also be used to create multiple different routes to the very same system. This can be achieved by creating two different VPN-IPv6 routes that have the same IPv6 part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used to decide which packets use which route. Spencer: "This allows the provider's BGP"? The adjective is probably implicit, but it's OK to be explicit, especially if you have a "provider's provider" network with a couple of BGPs for different ASes. Note that VPN-IPv6 addresses and IPv6 addresses are always considered by BGP to be incomparable. Spencer: "... to be distinct"? When a site is IPv4-capable and IPv6-capable, the same RD MAY be used for the advertisement of IPv6 addresses and IPv4 addresses. Alternatively, a different RD may be used for the advertisement of the IPv4 addresses and of the IPv6 addresses. Note however that in the scope of this specification, IPv4 addresses and IPv6 addresses will always be handled in separate contexts and no IPv4-IPv6 interworking issues and techniques will be discussed. Spencer: is the first MAY just for emphasis? It looks like 2119 language, but it doesn't seem to be (the "may" in the following sentence isn't all-capitals). Probably use lower case in both sentences? 3.2.1 BGP Next Hop encoding Definition of this policy (to request transport over IPv4 tunneling or IPv6 tunneling) is the responsibility of the network operator and is beyond the scope of this document. We note that it is possible for that policy to request transport over IPv4 (resp. IPv6) tunneling while the BGP speakers exchange IPv6 VPN reachability information over IPv6 (resp. IPv4). However, in that case, a number of operational implications are worth considering. In particular, an undetected fault affecting the IPv4 (resp. IPv6) tunneling data path and not affecting the IPv6 (resp. IPv4) data path, could remain undetected by BGP, which in turn may result in back-holing of traffic. Spencer: I understand "beyond the scope", but I wish we could make an operational recommendation here. You seem to have identified a choice that has problems if you choose it - would be nice to come out and say "NOT RECOMMENDED", or something like that. 3.2.1.1 BGP speaker requesting IPv6 transport An example scenario where both the global IPv6 address and the linklocal IPv6 address shall be included in the BGP Next Hop address field is where the IPv6 VPN service is supported over a multi-AS backbone with redistribution of labeled VPN-IPv6 routes between ASBRs (of different AS) sharing a common IPv6 subnet: in that case, both the global IPv6 address and the link-local IPv6 address shall be advertised by the ASBRs. Spencer: "link-local" should be hyphenated (as it is elsewhere), and ASBR hasn't been spelled out previously in this draft. 4. Encapsulation When tunneling is done using MPLS LSPs, the ingress PE Router MUST directly push the LSP tunnel label on the label stack of the labeled IPv6 VPN packet (i.e. without prepending any IPv4 or IPv6 header). This pushed label corresponds to the LSP starting on the ingress PE Router and ending on the egress PE Router. The BGP Next Hop field is used to identify the egress PE router and in turn the label to be pushed on the stack. In case the IPv6 address in the BGP Next Hop field is a IPv4-mapped IPv6 address, the embedded IPv4 address will determine the tunnel label to push on the label stack. In any other case, the IPv6 address in the BGP Next Hop field will determine the tunnel label to push on the label stack. Spencer - "When the IPv6 address in the BGP Next Hop"? 7. Carriers' Carriers Sometimes an IPv6 VPN may actually be the network of an IPv6 ISP, with its own peering and routing policies. Sometimes an IPv6 VPN may be the network of an SP which is offering VPN services in turn to its own customers. IPv6 VPNs like these can also obtain backbone service from an other SP, the ''Carrier's Carrier'', using the Carriers' Carrier method described in section 9 of [2547bis] but applied to IPv6 traffic. All the considerations discussed in [2547bis] for IPv4 VPN Carriers' Carrier apply for IPv6 VPN with the exception that the use of MPLS (including label distribution) between the PE and the CE pertains to IPv6 routes instead of IPv4 routes. Spencer - "an other" should be "another". 8. Multi-AS Backbones Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS to neighboring AS Spencer - missing period at the end of this sentence. 10. Management VPN Spencer - isn't this actually "VPN Management"? 11. Security Considerations The security considerations discussed for IPv4 VPNs in section 13 of [2547bis] are equally applicable to IPv6 VPNs. Spencer - boy, THIS seems minimal... are there NO IPv6 exposures the implementor and/or operator should be informed about? Section 12, on QoS, seems about the right level of thought and detail. 13. Scalability The scalability considerations summarized for IPv4 VPNs in section 15 of [2547bis] are equally applicable to IPv6 VPNs. Spencer - I would like to see any kind of list of scalability considerations that have been analyzed for this draft.