[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-v6inixp-04.txt WGLC
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.
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).
==============
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.
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!)
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.
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.
nits
----
- p3 reference to SNMP (RFC1157) should be updated as 1157 is
Histroci.
- p3 spell out "LAN" when first used
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings