[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-v6inixp-04.txt WGLC
Pekka,
Thank you Pekka for the review.
Please see my comments inline.
On Jan 20, 2010, at 12:11 PM, Pekka Savola wrote:
> On Mon, 18 Jan 2010, Fred Baker wrote:
>> This is to initiate a two week working group last call of draft-ietf-v6ops-v6inixp-04.txt.
>
> I agree with earlier comments that S 6 suggestions on MD5, GTSM, IPsec etc. may not be warranted especially in looking glass, route collection or similar scenarios. The suggestions in the latter part of the 2nd paragraph seem to be talking more about IPv6 peering sessions between participants than ones to the IX. I don't think this document needs to discuss the participants' BGP sessions (for exchanging routes to forward production traffic) at all, but if it does, I strongly think it needs to be a separate section.
(Roque) Section 6 is not about the bi-lateral peering sessions between members but about the sessions at the route-server. However, it is always just BGP. I will remover the MD5, GTSM, IPSEC comment as requested by several people.
What do you think about this text?:
--------------
6. Route-Server
IXPs may offer a Route-Server service, either for Multi-Lateral
Peering Agreements (MLPA) service, looking glass service or route-
collection service. IPv6 support needs to be added to the BGP
speaking router. The equipment should be able to transport IPv6
traffic and to support Multi-protocol BGP (MP-BGP) extensions for
IPv6 address family ([RFC2545] and [RFC4760]).
A good practice is that all BGP sessions used to exchange IPv6
network information are configured using IPv6 data transport. This
configuration style ensures that both network reachability
information and generic packet data transport use the same transport
plane. Because of the size of the IPv6 space, limiting the maximum number of IPv6
prefixes in every session should be studied.
External services should be available for external IPv6 access,
either by an IPv6 enabled web page or an IPv6 enabled console
interface.
--------------
>
> substantial
> -----------
>
> The exchange point addresses are intended for the peering mesh, e.g. from RIPE document: "Many Exchange Point operators require address space for the peering mesh that is independent from any of the address space in use by member networks." (http://www.ripe.net/ripe/docs/ripe-451.html)
>
> The last part of Section 3 describes an IXP operators decision that the addresses need to be globally routed. The latter part discusses globally routed services by the ISP. The IXP prefix is not meant for that, and it is not generally accepted in DFZ routing. For globally routable address space, other addresses should be obtained. The last sentence in S 3 mentions it briefly but this should be clearer.
>
> I suggest the following rewording:
>
> ======
> IPv6 prefixes for IXP LANs are typically publicly well known and
> taken from dedicated IPv6 blocks for IXP assignments reserved for
> this purpose by the different RIRs. These blocks are usually
> only meant for addressing the exchange fabric, and may be filtered
> out by DFZ (Default Free Zone) operators. When considering the
> routing of the IXP LANs two options are identified:
>
> o IXPs may decide that LANs should not to be globally routed in
> order to limit the possible origins of a Denial of Service (DoS)
> attack to its participants' AS boundaries. In this configuration
> participants may route these prefixes inside their networks (e. g.
> using BGP no-export communities or routing the IXP LANs within the
> participants' IGP) to perform fault management. Using this
> configuration, the monitoring of the IXP LANs from outside of its
> participants' AS boundaries is not possible.
>
> o IXP may decide that LANs should (attempt to be) be globally
> routed. In this case, IXP LANs monitoring from outside its
> participants' AS boundaries may be possible but the IXP LANs
> will be vulnerable to DoS from outside of those boundaries.
>
> Additionally, possible IXP external services (such as dns, web
> pages, ftp servers) need to be globally routed. These should be
> addressed from separate address blocks, either from upstream
> providers' address space, or separate independent assignments.
> Strict prefix length filtering could be a reason for requesting
> more than one /48 assignment from a RIR (i.e. requesting one /48
> assignment for the IXPs LANs that may not be globally routed and a
> different, non-IXP /48 assignment for the IXP external services
> that will be globally routed).
(Roque) So, the changes are in the first and last paragraphs of the section where you are adding the possibility of using PA space for services. I have no problem with the suggestion.
> ==============
>
> semi-editorial/substantial
> --------------------------
>
> 2. independent LAN: an exclusive IPv6 LAN is created for IPv6
> traffic. If IXP participants are already using Virtual LAN
> (VLAN) tagging on the interfaces of their routers that are facing
> the IXP switch, this only requires passing one additional VLAN
> tag across the interconnection. If participants are using
> untagged interconnections with the IXP switch and wish to
> continue doing so, they will need to provision a separate
> physical port to access the IPv6-specific LAN.
>
> .. the last sentence assumes untagged VLAN which is not given. From textual perspective, "If participants are using.." is confusing. This is the design decision of the IXP _operator_, not the (individual) participants. Example rewording:
> 2. independent LAN: an exclusive IPv6 LAN is created for IPv6
> traffic. If IXP already uses Virtual LAN (VLAN) tagging,
> participants are only required to passing one additional VLAN
> tag across the interconnection. If IXP does not use VLAN
> tagging, VLAN tagging needs to be established. Previous use
> may continue untagged as a "native VLAN" or be transitioned to
> a tagged VLAN.
>
(Roque) Your proposal does not cover the case of maintaining separate Physical ports for v4 and v6. What about this rewording:
2. independent LAN: an exclusive IPv6 LAN is created for IPv6
traffic. If IXP already uses Virtual LAN (VLAN) tagging,
participants are only required to passing one additional VLAN
tag across the interconnection. If IXP does not use VLAN
tagging, either VLAN tagging is established (where previous use may
continue untagged as a "native VLAN" or be transitioned to a tagged VLAN)
or a separate physical port is configure for each participant IPv6 traffic.
> The "independent LAN" configuration provides a physical separation
> for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and
> IPv6 traffic. However, it can be more costly in both capital
> expenses (if new ports are needed) and operational expends.
>
> .. The last sentence is not the whole picture, and should be deleted or rephrased. Additional ports are not necessary, see above. FWIW, typically participants terminate IPv4 and IPv6 LANs at the same device and these are just logical subinterfaces. As such the next sentence also requires rewording as its unnecessarily biased:
> Conversely, the dual-stack implementation allows a quick and capital
> cost-free start-up for IPv6 support in the IXP, allowing the IXP to
> avoid transforming untagged ports into tagged ports.
>
> The only technical requirement for IPv6 referring link MTUs is that
> they need to be greater than or equal to 1280 octets [RFC2460].
> Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes.
>
> .. is this IP MTU? I do not think 9216 is true in this case. E.g. in Juniper equipment (common in IXP PE routers) the max _Ethernet_ MTU is 9192 bytes (9188 IP MTU). I do not believe there are common router products that even support IP MTU of 9216 bytes (yes, some switches support ethernet mtu of 9216 bytes but that's different). Because eth mtu changes depending on vlan tagging and/or whether you count various ethernet stuff in it, it's best to only discuss IP mtu here.
>
> The MTU size
> for every LAN in an IXP should be well known by all its
> participants.
>
> .. you could also make this stronger and replace "well known and uniformally adhered to" -- there will be blackholing if everyone is not using the same MTU (esp. issues with jumbo sizes! and if you change vlan tagging, the mtu "calculations" might change unless you're careful!)
>
(Roque) What about the following reworking for this complete section?:
--------------------
The "independent LAN" configuration provides a physical or logical separation
for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and
IPv6 traffic. However, if implemented by using different physical ports instead of using vlan tagging, it can be more costly in both capital
expenses (as new ports are needed) and operational expenses.
Conversely, the "dual-stack" implementation while allows a quick IPv6 support in the IXP. In this implementation traffic-split for statistical analysis would require the use of flows techniques such as IPFIX [RFC5101] considering the different ether-types (0x0800 for IPv4, 0x0806 for ARP and 0x86DD for
IPv6).
The only technical requirement for IPv6 referring link MTUs is that
they need to be greater than or equal to 1280 octets [RFC2460].
The MTU size for every LAN in an IXP should be well known by all its participants.
--------------------
> 7. External and Internal support
>
>
> Some external services that need to have IPv6 support are traffic
> graphics, DNS, FTP, Web, Route Server and Looking Glass. [...]
>
> .. I'd maybe add that "In many cases, these are subcontracted or otherwise acquired from exchange participants or third parties." This is the "ISP-side" of IXP business and that should be kept distinct from the IPv6 peering fabric issues.
(Roque) I would rather not get to particulars here, the important is that it is something to put in their "checkbox".
>
> 10. Security Considerations
>
>
> This memo includes procedures for monitoring and/or avoiding
> particular ICMPv6 traffic at IXPs' LANs. It also mentions how to
> limit IPv6 DoS attacks to the IXP switch fabric by not globally
> announce the IXP LANs prefix.
>
>
> .. Maybe it should be mentioend here that neither the IPv4 ARP filtering, nor the describes IPv6 multicast filtering will prevent Ethernet loops from causing mischief in the LAN.
>
> The latter sentence should be removed or rephrased per above.
(Roque) What about this text:
This memo includes procedures for monitoring and/or avoiding
particular ICMPv6 traffic at IXPs' LANs. None of these methods prevent Ethernet loops
caused by mischief in the LAN. The document also mentions how to
limit IPv6 DoS attacks to the IXP switch fabric by not globally
announce the IXP LANs prefix.
>
> nits
> ----
>
> - p3 reference to SNMP (RFC1157) should be updated as 1157 is Histroci.
(Roque) I will replace it by RFC3411.
> - p3 spell out "LAN" when first used
>
(Roque) ok
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings