Subject: Re: draft-ietf-v6ops-v6inixp-04.txt WGLC

From: Roque Gagliano <[email-masked]>
Date: Mon, 1 Feb 2010 09:43:21 +0100

Eduardo,

Thank you for your message. Please see my comment inside.

> 
> So, removing the following part:
> "      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."
> 

(Roque) As I stated in my previous email, this text was discussed in a previous version of the draft. It does represent a common practice and it is stated in the document as an option. I still do not see the benefit of removing this paragraph.

Roque.

> Thanks,
> -- 
> Eduardo Ascenço Reis

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 2 Feb 2010 17:36:25 +0100

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' 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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Feb 2010 08:59:20 +0200 (EET)

> What do you think about this text?:
...

Works for me.

>> 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)
...
> (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.

My suggested version does more than just suggest PA space for 
services, it also describes that it's not necessarily a good idea to 
run services off the IXP fabric space.  If if you're fine with the 
suggested text, it's fine with me.

>      or a separate physical port is configure for each participant IPv6 traffic.

s/passing/pass/ above (that was wrong in my suggestion above), in 
priniciple I'm OK with this.

Are you aware of IXes which provide separate Physical ports for v4 and 
v6?  While you're technically correct, this seems like a lot of waste 
and I doubt there would be interest for that approach.

If it's actually used somewhere, I'm starting to wonder if 
"independent LAN" would be clearer if it was split into two different 
options, "independent VLAN" and "independent port".  These have so 
different properties in many ways, as was shown in my next 
comments that have now been adapted.

> (Roque) What about the following reworking for this complete section?:

I'm fine with that text.

>> .. 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".

The reason I was saying this is that I think this isn't an IX-specific 
issue.  The most relevant are probably Route Server and looking glass, 
but otherwise this is pretty much identical to how an enterprise or an 
ISP would run its support services.  As such I think adding a 
statement like I suggested above would clarify to the reader that 
these are not IX-specific services, and indeed, in many cases the IX 
does not need to provide them on its own.

These are IMHO also not a requirement for an IX to get 
globally-routable PI or PA space and that's another reason why it's 
worth spelling out.

>   announce the IXP LANs prefix.

I think the global announce text could maybe be slightly better (its 
implying that the default is globally announce instead of NOT 
announce), but it's not technically wrong so I'm fine with it.

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 4 Feb 2010 15:53:03 +0100

Hi Pekka,
Thanks again for your comments.I believe we came up to one section to be improved. 

Here is the proposed text for section 2 using your feedback:

---------------------
2.  Switch Fabric Configuration

   An Ethernet based IXP switch fabric implements IPv6 over Ethernet as
   described in [RFC2464].  Therefore, the switching of IPv6 traffic
   happens in the same way as in IPv4.  However, some management
   functions may require explicit IPv6 support (such as switch
   management, SNMP [RFC3411] support and flow analysis exportation) and
   this should be assessed by the IXP operator.

   There are two common configurations of IXP switch ports to support
   IPv6:

   1.  dual-stack LAN (Local Area Network): when both IPv4 and IPv6
       traffic share a common LAN.  No extra configuration is required
       in the switch.

   2.  independent VLAN (Virtual Local Area Network): when an IXP
       logically separates IPv4 and IPv6 traffic in different VLANs.

   In both configurations, IPv6 and IPv4 traffic can either share a
   common physical port or use independent physical ports.  The use of
   independent ports can be more costly in both capital expenses (as new
   ports are needed) and operational expenses.

   When using the same physical port for both IPv4 and IPv6 traffic,
   some changes may be needed at the participants' interfaces
   configurations.  If the IXP implements the "dual-stack
   configuration", IXP participants will configure dual-stack
   interfaces.  On the other hand, if the IXP implements the
   "independent VLAN configuration", IXP participants are required to
   pass one additional VLAN tag across the interconnection.  In this
   case, if the IXP did not originally use VLAN tagging, VLAN tagging may to
   be established and previous use may continue untagged as a "native
   VLAN" or be transitioned to a tagged VLAN.  The "independent VLAN"
   configuration provides a logical separation of IPv4 and IPv6 traffic,
   simplifying separate statistical analysis for IPv4 and IPv6 traffic.
   Conversely, the "dual-stack" configuration (when performing separate
   statistical analysis for IPv4 and IPv6 traffic) would require the use
   of flows techniques such as IPFIX [RFC5101] to classify traffic based
   on 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.

---------------------

Roque

On Feb 3, 2010, at 7:59 AM, Pekka Savola wrote:

> My suggested version does more than just suggest PA space for services, it also describes that it's not necessarily a good idea to run services off the IXP fabric space.  If if you're fine with the suggested text, it's fine with me.
> 
> s/passing/pass/ above (that was wrong in my suggestion above), in priniciple I'm OK with this.
> 
> Are you aware of IXes which provide separate Physical ports for v4 and v6?  While you're technically correct, this seems like a lot of waste and I doubt there would be interest for that approach.
> 
> If it's actually used somewhere, I'm starting to wonder if "independent LAN" would be clearer if it was split into two different options, "independent VLAN" and "independent port".  These have so different properties in many ways, as was shown in my next comments that have now been adapted.
> 
> The reason I was saying this is that I think this isn't an IX-specific issue.  The most relevant are probably Route Server and looking glass, but otherwise this is pretty much identical to how an enterprise or an ISP would run its support services.  As such I think adding a statement like I suggested above would clarify to the reader that these are not IX-specific services, and indeed, in many cases the IX does not need to provide them on its own.
> 
> These are IMHO also not a requirement for an IX to get globally-routable PI or PA space and that's another reason why it's worth spelling out.
> 
> 
> I think the global announce text could maybe be slightly better (its implying that the default is globally announce instead of NOT announce), but it's not technically wrong so I'm fine with it.
> 
> --

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Feb 2010 12:35:42 +0200 (EET)

> Here is the proposed text for section 2 using your feedback:
..

Looks good to me.