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

From: Fred Baker <[email-masked]>
Date: Mon, 18 Jan 2010 08:00:11 -0800

This is to initiate a two week working group last call of draft-ietf- 
v6ops-v6inixp-04.txt. Please read it now. If you find nits (spelling  
errors, minor suggested wording changes, etc), comment to the authors;  
if you find greater issues, such as disagreeing with a statement or  
finding additional issues that need to be addressed, please post your  
comments to the list.

We are looking specifically for comments on the importance of the  
document as well as its content. If you have read the document and  
believe it to be of operational utility, that is also an important  
comment to make.

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Jan 2010 08:30:56 +1030

Hi,

On Mon, 18 Jan 2010 08:00:11 -0800

> finding additional issues that need to be addressed, please post your  

I think this text needs to be changed in Section 3, Addressing Plan.

"IXPs will normally use manual address configuration.  Address prefix
   between /64 and /127 are technically feasible [RFC4291]."

RFC4291 says 

" For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format."

If people wish to use longer than /64s, that is up to them. However I
think that the text in this draft implies, by referring to RFC4291 the
way it does, that this is supported in the IPv6 Addressing Archtecture.
I'd suggest something like the following:

"IXPs will normally use manual address configuration. The IPv6
ADdressing Architecture [RFC4291] requires that interface identifiers
are 64 bits in size for prefixes starting with binary 000, resulting in
a maximum prefix length of /64. Longer prefix lengths up to /127 have
been used operationally. If prefix lengths longer than 64 bits are
chosen, the implications described in [RFC3627] need to be considered."

> believe it to be of operational utility, that is also an important  

I think it is a good document. Anything that helps people avoid
duplicating the effort of working out how to deploy IPv6 is important.

---

From: Andy Davidson <[email-masked]>
Date: Mon, 18 Jan 2010 22:08:02 +0000

On 18 Jan 2010, at 16:00, Fred Baker wrote:

> This is to initiate a two week working group last call of draft-ietf-v6ops-v6inixp-04.txt. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
> 
> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

I think it will be interesting to folk building IXPs, sure let's do work on this document.

3 - Addressing Plans - part 2 - the author may like to describe that 32-bit ASN will require spanning across multiple biglets in the ipv6 address - the example possibly suggests that the ASN encoding will neatly fit into one portion of the address, and this is not true.

6 - Route servers - md5 should be considered - I think this advice should be taken out, as this recommendation is not generally accepted, and the functioning/configuration of a route-server is well outside the scope of this document.

6 - Route servers - we may like to publish some information on v6 filtering to promote good hygiene between route-server peers.

Missing - link local address recommendations - Right now on an IXP operational mailing list, some folk are making observations about link local addressing used by IXP participants, and a recommendation may follow.  It may be sensible to explicitly forbid traffic for link local protocols other than ND.

I am pleased to see the reference to ra-guard, as an operator of l2 services I am looking forward to being able to roll this out to all of my ports facing ixp participants and LAN access users !

Andy

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 19 Jan 2010 10:28:41 +0100

Hi Mark,

This text when to several revision, I like the text you are proposing.

Roque

---

From: Eduardo Ascenço Reis <[email-masked]>
Date: Wed, 20 Jan 2010 00:34:02 -0200

Hi Fred and Fellows,

2010/1/18 Fred Baker <[email-masked]>:

> We are looking specifically for comments on the importance of the document
> as well as its content. If you have read the document and believe it to be
> of operational utility, that is also an important comment to make.
>

I am directly involved with IXP (http://ptt.br/) - already with IPv6
support - and believe that this is an important document that should
be discussed and supported by this working group.

I will do some comments on separated messages.

-- 

Eduardo Ascenço Reis

---

From: Eduardo Ascenço Reis <[email-masked]>
Date: Wed, 20 Jan 2010 00:54:52 -0200

2010/1/18 Andy Davidson <[email-masked]>:

> 6 - Route servers - md5 should be considered - I think this advice should be
> taken out, as this recommendation is not generally accepted, and the
> functioning/configuration of a route-server is well outside the scope of
> this document.

I agree with Andy and also suggest that the following sentence to be
removed from the document:

"The use of MD5 [RFC2385] or IPSEC [RFC4301] to
   authenticate the BGP sessions and the use of GTSM (The Generalized
   TTL Security Mechanism) [RFC3682] should be considered."

I understand that these mechanisms may help securing the BGP session,
but also that they do not fit well on an IPv6 operational document.

> 6 - Route servers - we may like to publish some information on v6 filtering
> to promote good hygiene between route-server peers.

I agree.

I also suggest to replace the word studied with considered on the
following sentence:
"Because of the size of the IPv6 space, limiting the maximum number of IPv6
   prefixes in every session should be studied."

[]s,

-- 

Eduardo Ascenço Reis

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Jan 2010 13:11:49 +0200 (EET)

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

---

From: Eduardo Ascenço Reis <[email-masked]>
Date: Thu, 28 Jan 2010 00:55:55 -0200

Hi Roque,

I would like to recall a previous discussion.

2009/11/9 Eduardo Ascenço Reis <[email-masked]>:
> ...
> 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.
> ...
> I recommend for AS to use next-hop-self on iBGP sessions, by doing
> that there will be no need to redistribute IXP prefix into their IGP.
>

2009/11/20 Roque Gagliano <[email-masked]>:
>
> The routing of the IXPs LANs inside the participants has to do with the use
> of uRPF and being able to perform traceroutes. Using next-hop-self to your
> iBGP sessions does not solve this problem.
>

I did not get your points.

I agree that Unicast Reverse Path Forwarding (uRPF) may be a good
solution for IPv6 IXP participants in order to get some extra
protection against abuse conditions [1].

As uRPF is normally implemented on the network edge, the AS border
router connected to the IXP already knows its IPv6 netblock (directly
connected) and can check IPv6 source address against it. By the way,
the exchange traffic that the AS may be more interested to check with
uRPF wil have IPv6 source address from its peers prefixes.

So there is no relation between uRPF and IPv6 IXP netblock being
advertised on participant IGP.

Regarding traceroute tests, if IPv6 IXP netblock is not know by a
participant IGP, it will only affect tests done by a host inside this
network against IXP IPv6 address, which may be something good. The
traceroute originator host can normally receive icmp unreachable
packets from intermediate routers with a non-reachable IPv6 source
address.

I understand that the fundamental routing point about this discussion
is if the IPv6 prefixes learned by a participant AS have NEXT_HOP
attribute reachable for the AS BGP enable routers, which may be done
by routing the IPv6 IXP netblock inside the AS IGP or changing the
prefixes NEXT_HOP for an AS internal IPv6 address (e.g. loopback from
router connect to IXP).

I personally prefer the second option and recommend that to be
included in this document as an alternative approach.

Thanks,

-- 

Eduardo Ascenço Reis

[1] http://lacnic.net/documentos/lacnicxii/presentaciones/napla/06_Eduardo_Ascenco_Reis.pdf

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 28 Jan 2010 21:58:35 +0100

Thanks Andy for your comment, sorry for the delay.

Please see answers inline.

> 3 - Addressing Plans - part 2 - the author may like to describe that 32-bit ASN will require spanning across multiple biglets in the ipv6 address - the example possibly suggests that the ASN encodi…

I had that comment for the previous example using the decimal representation.  What about adding: 
"In this case a maximum of 8 characters will be needed to represent 32 bits ASNs." 

> 6 - Route servers - md5 should be considered - I think this advice should be taken out, as this recommendation is not generally accepted, and the functioning/configuration of a route-server is well…

the idea was to name the variants of security configurations that are normally configured. However, if there is consensus on removing this text, I see no problem.

> Missing - link local address recommendations - Right now on an IXP operational mailing list, some folk are making observations about link local addressing used by IXP participants, and a recommenda…

I believe that is the information included in section 4.1 (4.1.  Multicast Support and Monitoring for ND at an IXP).

Do you have particular comments on this section?

> I am pleased to see the reference to ra-guard, as an operator of l2 services I am looking forward to being able to roll this out to all of my ports facing ixp participants and LAN access users !

Good!.

Thanks again,
Roque.

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 28 Jan 2010 23:03:21 +0100

Hi Eduardo,

Please see the comments inline.

> advertised on participant IGP.

(Roque) Eduardo, the problem is with downstream ISP customer's.

IXP ---- ISP1 --- ISP2 

ISP2 implements uRPF, in order to help him with troubleshooting without breaking uRPF the ISP1 announce the IXP LAN.

> packets from intermediate routers with a non-reachable IPv6 source

(Roque) In the previous example, for each traceroute passing by the IXP LAN, the packet with source IP in the IXP LAN will be discarded thanks to uRPF.

> prefixes NEXT_HOP for an AS internal IPv6 address (e.g. loopback from

I do not get your point here. Are we still talking about the IXP LAN prefix? 

Regards,
Roque.

---

From: Eduardo Ascenço Reis <[email-masked]>
Date: Fri, 29 Jan 2010 01:10:02 -0200

Hi Roque,

> ISP2 implements uRPF, in order to help him with troubleshooting without breaking uRPF the ISP1 announce the IXP LAN.

Are you saying that ISP1 should advertise (BGP) the IPv6 Prefix
corresponding to IXP LAN to ISP2?

I understand that we are discussing about the case when IPv6 IXP LAN
is not globally routed. Considering that ISP1 is not IXP
owner/operator it has no authority to generate an IPv6 prefix on its
BGP Internet table, neither advertise it to outside its domain.

> (Roque) In the previous example, for each traceroute passing by the IXP LAN, the packet with source IP in the IXP LAN will be discarded thanks to uRPF.

This is true for test from ISP2 to others IXP participants and if ISP2
has uRPF on its link to ISP1.

But ISP2 is not an IXP participant and the IPv6 IXP LAN is not
globally routed. So that is it.

> I do not get your point here. Are we still talking about the IXP LAN prefix?

Sure. We are discussing about Multilateral Peering Agreements, when
participants normally establish their BGP sessions using IXP IPv6 LAN
address and it is not globally routed.

Considering that and in order for IPv6 prefixes learned from IXP
peering sessions to be reachable inside their networks, participants
AS have basically two options:
1. Route IPv6 IXP LAN into their IGP.
2. Change NEXT_HOP attribute to something reachable and under its
domain (e.g. a /128 from one of its IPv6 netblocks).

I still prefer the second option and recommend that to be included in
this document as an alternative approach.

Thanks,

-- 

Eduardo Ascenço Reis

---

From: Roque Gagliano <[email-masked]>
Date: Fri, 29 Jan 2010 22:03:38 +0100

Hi Eduardo,

Thanks for your comments. Please see my responses inline.

> corresponding to IXP LAN to ISP2?

(Roque)
I am not saying that it should or should not but that it a common practice to avoind the mentioned problem. This is the correspondent text in the document:

(Section 3)

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

This specific text was extensively discussed in this WG, please see the following messages:

http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00682.html
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00680.html
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00694.html
http://ops.ietf.org/lists/v6ops/v6ops.2009/msg00530.html

Do you have any specific improvement to the text?

> BGP Internet table, neither advertise it to outside its domain.

(Roque)
This practice has to do with its customers (downstream), not globally advertisement.

Funny that you mentioned authorization, because this issue came out in the SIDR mailing list a couple of month ago about how to handle this problem. The conclusion was that IXP operators would have to authorize each participant to originate the IXP LAN prefix issuing a ROA for each participant ASN.

You can read the thread at:
http://www.ietf.org/mail-archive/web/sidr/current/msg00975.html

> domain (e.g. a /128 from one of its IPv6 netblocks).

(Roque) So, you are basically talking about the configuration of the iBGP sessions from the router to its own network. I do not think this belongs to this document.

Roque.

---

From: Eduardo Ascenço Reis <[email-masked]>
Date: Mon, 1 Feb 2010 00:48:16 -0200

Hi Roque,

This is my last message to this thread just to conclude the
participation and enforce the go ahead to this document.

I was previously trying to highlight that globally routing (or not)
IXP IPv6 LAN is not only related to measurement and security (DoS)
points, but also with routing between IXP participants. And how they
deal with NEXT_HOP attribute on IPv6 prefixes learned from other
participants is an important matter.

But I also agree that this topic is out of scope to this document.

Considering that, I would like to suggest the following change to the text:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3.  Addressing Plan
(...)

 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 particpants' AS boundaries.

   o  IXP may decide that LANs should be globally routed.  In this case,
      IXP LANs monitoring from outside its participants' AS boundaries
      is possible but the IXP LANs will be vulnerable to DoS from
      outside of those boundaries.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

Thanks,

-- 

Eduardo Ascenço Reis