Subject: Draft IPv6 in an IXP

From: Roque Gagliano <[email-masked]>
Date: Wed, 10 Dec 2008 14:35:21 -0600

Dear Friends,

working in another project I wrote a document about options for  
implementing IPv6 in an IXP. I submit this information as an Internet  
Draft and I wanted to get feedback from this working group.

Draft:
http://www.ietf.org/internet-drafts/draft-rgaglian-v6ops-v6inixp-00.txt

regards,

Roque Gagliano
LACNIC

---

From: [email-masked]
Date: Wed, 10 Dec 2008 23:30:45 +0000

On Wed, Dec 10, 2008 at 02:35:21PM -0600, Roque Gagliano wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear Friends,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> 
> iEYEARECAAYFAklAKAkACgkQnk+WSgHpbO4MWQCfWLgdjkfDFRZ04jRF6RDP5bCi
> 8UEAn1LLpT74/LEtIbzgVgTRCSnoOUEq
> =y/cx
> -----END PGP SIGNATURE-----

	minor points:

	) is the prefix used in the examples from the reserved prefix list or
	  are you using a live prefix?

	) the use of an encoded ASN is a holdover from a previous IPv6 addressing
	  plan.  It might be worthwhile to reference that RFC

	) more than just the five RIR's have and allocate prefixes for use in/at
	  exchanges.

	) in at least a dozen exchanges, there is an algorithmic mapping between
	  the v4 and v6 assignments.

--bill

---

From: Truman Boyes <[email-masked]>
Date: Wed, 10 Dec 2008 21:24:52 -0500

Hi,

A few comments:

Second 2, bullet #2, 3rd line reads: "Otherwise, it may required a  
new". Should possibly read "Otherwise, it may require a new...."

In the sentence that reads "However, it can be more costly in both  
capital expends ", did you mean "capital expenses"?

Section 3.4, the statement, "should also applies", should read "should  
also apply".

In the security section is it worth mentioning a stance on filtering  
type 0 routing headers at this critical place in the Internet?

Kind regards,
Truman Boyes

On 10/12/2008, at 3:35 PM, Roque Gagliano wrote:

> implementing IPv6 in an IXP. I submit this information as an  
> Internet Draft and I wanted to get feedback from this working group.
>
> Draft:

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 11 Dec 2008 08:56:59 +0000

> new". Should possibly read "Otherwise, it may require a new...."

	Or "Otherwise, a new physical port may be required for
	every ..."?

> capital expends ", did you mean "capital expenses"?

	Or "capital costs"?

	Best regards,
	Niall O'Reilly

---

From: Philip Smith <[email-masked]>
Date: Mon, 15 Dec 2008 16:12:49 +1000

Hi Roque,

> http://www.ietf.org/internet-drafts/draft-rgaglian-v6ops-v6inixp-00.txt

This is a nice document and certainly reflects what I see happening in
several IXPs worldwide.

Thank you for taking the time to write this up!

philip
--

---

From: Michuki Mwangi <[email-masked]>
Date: Mon, 15 Dec 2008 12:49:42 +0300

Hi Roque,

A similar addressing plan for IXPs with a slight variation to addressing
plan option 4 is what they use in Tanzania - where they convert the last
bits of theIPv4 decimal number into hexadecimal and replace the last
bits with the hex value.

More information and sample is available at

http://tix.or.tz/ipv6/

This is a great document.

Regards,

Michuki.

---

From: Frank Habicht <[email-masked]>
Date: Tue, 16 Dec 2008 09:06:11 +0300

> bits of theIPv4 decimal number into hexadecimal and replace the last

... for no particular reason.

> This is a great document.

I agree. Great work, Roque.
Nothing to add from here.

Frank

---

From: Joe Abley <[email-masked]>
Date: Tue, 16 Dec 2008 09:26:57 -0500

> http://www.ietf.org/internet-drafts/draft-rgaglian-v6ops- 

Thanks for writing this up. Some minor comments follow.

You make the assumption in the document that the exchange is a layer-2  
facility. While this is religion for some, and (I think it would be  
fair to say) the most common infrastructure deployed with the label  
"exchange point" today, there are certainly examples of infrastructure  
that exist to exchange Internet traffic that do not look like this.

Similarly, there are exchange points (a dwindling number, no doubt)  
which do not necessarily function by the connection of peers to a  
single subnet (e.g. ATM fabrics which map individual PVCs directly  
between members, who are free to number the endpoints of the virtual  
circuits in any fashion they see fit).

You might observe near the top of the document that your treatment  
concerns layer-2 exchange points with a common subnet connecting  
participants, rather than proceeding as if no other implementation of  
"exchange point" exists. This would make the context more clear, I  
think, for those who happen to be involved in an exchange point that  
looks different. Observing that this is the most usual meaning of  
"exchange point" at the time of writing would not be unreasonable.

>    When selecting the use of static IIDs, there are different  
> options on
>    how to "intelligently" fill its 64 bits (or 16 hexadecimal
>    characters).  A list of IID selection mechanisms follows:

There is a possible inference there that the four options that follow  
are the only possible ways that an exchange point operator could  
choose a numbering scheme.

It would be better to make it clearer that what you are doing is  
listing four possibilities, and in practice exchange point operators  
are free to choose whatever scheme they like, regardless of whether it  
is listed in this document or not.

In section 4, you say:

>    PTR records for all addresses assigned to members should be  
> included
>    in the IXP reverse zone under "ip6.arpa".

The manner in which reverse DNS in IPv6 is handled has changed once in  
the past. It's slightly difficult to imagine it changing again, but I  
guess you never know. You'd avoid the possibility of this document  
giving out-of-date advice in the future altogether by simply avoiding  
the mention of "ip6.arpa". There is a draft that surely one day will  
be published that you could reference in order to support your  
assertion that reverse DNS is worth doing -- see draft-ietf-dnsop- 
reverse-mapping-considerations-06.txt.

As you describe dual-stack support for various ancillary services an  
exchange point operator might make available to connected  
organisations, you might mention that it's not necessary for any of  
that work to be done as a prerequisite for bilateral IPv6 peering  
across the fabric.

You make mention in a couple of places to extra precautions that  
participants might take when setting up their routers to do v6 peering  
(e.g. disabling router advertisements, setting a common MTU, avoiding  
protocols which generate link-local multicast traffic). It would be  
useful for that advice to be grouped together into a single section, I  
think, so that it is easy to find when someone makes reference to your  
document in the future by way of helping people configure their routers.

Editorially, I find your language in the draft very clear, and easy to  
follow.

Joe

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 16 Dec 2008 15:11:23 -0200

Hi bill,
thanks for the comments.
> 	  are you using a live prefix?

both IPv6 and ASN numbers are from documentation pool. I took a 240  
IPv4.
> 	  plan.  It might be worthwhile to reference that RFC

do you have that number? I have not read that before.

> 	) more than just the five RIR's have and allocate prefixes for use  

You mean NIR/LIRs? I should add those.

> 	  the v4 and v6 assignments.

Yes, I believe that is a variation of case (3), I can add that  
observation.

Thanks again,

Roque

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 16 Dec 2008 15:23:07 -0200

Truman,

I took your editorial notes.

> type 0 routing headers at this critical place in the Internet?

Well, ASIK, Type 0  routing headers are filtered now by router  
software, not sure there is an "operational" practice here. But it is  
a good point.

Roque

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 16 Dec 2008 15:25:24 -0200

michuki,

what I did for a new version was generalizing point 3 as relating the  
v6 address to the v4 address. And leaving the note of the example.

Roque

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 16 Dec 2008 15:39:31 -0200

Joe,

Thanks for the comments.

On Dec 16, 2008, at 12:26 PM, Joe Abley wrote:

> You make the assumption in the document that the exchange is a  
> layer-2 facility. While this is religion for some, and (I think it  
> would be fair to say) the most common infrastructure deployed with  
> the label "exchange point" today, there are certainly examples of  
> infrastructure that exist to exchange Internet traffic that do not  
> look like this.
>
> participants, rather than proceeding as if no other implementation  
> of "exchange point" exists. This would make the context more clear,  
> I think, for those who happen to be involved in an exchange point  
> that looks different. Observing that this is the most usual meaning  
> of "exchange point" at the time of writing would not be unreasonable.
>

So, I would say that I am supposing an ethernet switch fabric, yes. I  
can refer to that in the introduction as:
The document assumes an Ethernet switch fabric, algthouh other layer 2  
devices can be deployed.

> There is a possible inference there that the four options that  
> follow are the only possible ways that an exchange point operator  
> could choose a numbering scheme.
>
> are free to choose whatever scheme they like, regardless of whether  
> it is listed in this document or not.
>

good point.

> The manner in which reverse DNS in IPv6 is handled has changed once  
> in the past. It's slightly difficult to imagine it changing again,  
> but I guess you never know. You'd avoid the possibility of this  
> document giving out-of-date advice in the future altogether by  
> simply avoiding the mention of "ip6.arpa". There is a draft that  
> surely one day will be published that you could reference in order  
> to support your assertion that reverse DNS is worth doing -- see  
> draft-ietf-dnsop-reverse-mapping-considerations-06.txt.

well the document is currently expired.

> that work to be done as a prerequisite for bilateral IPv6 peering  

you meant that the operator might be unaware that the participant are  
exchanging IPv6 sessions using link local.

> participants might take when setting up their routers to do v6  
> peering (e.g. disabling router advertisements, setting a common MTU,  
> avoiding protocols which generate link-local multicast traffic). It  
> would be useful for that advice to be grouped together into a single  
> section, I think, so that it is easy to find when someone makes  
> reference to your document in the future by way of helping people  
> configure their routers.
>
> Editorially, I find your language in the draft very clear, and easy  
> to follow.
>

thanks.

---

From: Joe Abley <[email-masked]>
Date: Tue, 16 Dec 2008 12:45:51 -0500

On 16 Dec 2008, at 12:39, Roque Gagliano wrote:

>> There is a draft that surely one day will be published that you  
>> could reference in order to support your assertion that reverse DNS  
>> is worth doing -- see draft-ietf-dnsop-reverse-mapping- 
>> considerations-06.txt.
>

I don't believe you should infer from that that it has been dropped  
(but no doubt Andrew would let you know the full story; try [email-masked] 
).

>> As you describe dual-stack support for various ancillary services  
>> an exchange point operator might make available to connected  
> you meant that the operator might be unaware that the participant  
> are exchanging IPv6 sessions using link local.

No, actually -- I meant that even if the web page, the traffic  
collection, the route server, etc, etc are not dual-stack capable, the  
fact that you've assign some v6 addresses to peers means they can peer  
regardless. Your document seems to suggest (by my reading) that all  
that dual-stack work is required before an exchange point can be said  
to support v6, which I think is not the case.

I don't think suggesting that BGP peering using link-local addresses  
is sensible is a good idea, but perhaps that's just my own religion  
showing through.

Joe

---

From: bill fumerola <[email-masked]>
Date: Tue, 16 Dec 2008 17:06:54 -0800

[ N.B. i wrote this last wednesday and haven't had time to update it to
incorporate or remove suggestions made by other WG members. nor have
i completed it, but since this document is being discussed i thought i
would just send out what i had. ]

> http://www.ietf.org/internet-drafts/draft-rgaglian-v6ops-v6inixp-00.txt

this review is not a complete review, nor do i agree w/ everything that
i have not disagreed with below. i'm including both grammatical and
technical nits. if this document is going to go further (either as a WG
item or individual publication), i'll commit to reviewing it further.

all sections:
- half the sections end with a trailing period, half do not. they
  shouldn't as they are not sentences.
- there is no table of contents.

section 2:
"The Switch Fabric is a Layer 2 device"
not really. the switch fabric may be more than one switch. there may
be repeaters, multiple sites connected over a metro LAN, and much more
complex configurations. use words that refer to Ethernet and LANs more
generically, etc. avoid wording that implies there is One Switch. the
important point here is that IPv6 IXPs run on IPv6 over Ethernet [RFC2464]
and not (say) IPv6 over ATM [RFC2492].

"classic configurations":
section 2 may/may not be implemented as a VLAN, it could be a physically
 separate LAN
could include a third section: .1q trunks (which avoids the need for
 twice as many physical ports)

VLANs provide a _logical_, not physical separation

s/On the other side// ("On the other hand" is the English idiom)

"In the dual-stack model, statistical analysis on traffic can easily
separate traffic by EtherType."

"access mode ports into tagged" = "untagged ports into tagged ports"
   access mode is a cisco-ism

from section 3, IID selection:

       *  IPv6 Address: 2001:DB8::6449:6000:0000:0001/64 or its
              equivalent representation 2001:DB8::6:4496:1/64

those are not equivalent:
2001:DB8::6449:6000:0000:0001 = 2001:DB8::6449:6000:0:1
2001:DB8::6:4496:1/64 = 2001:0db8:0000:0000:0000:0006:4496:0001

   4.  A forth approach might be based on IXP the membership ID for that
          provider.

"fourth"

   The current practice that applies to IPv4 about publishing IXP
   allocations to the DFZ (Default Free Zone) should also applies to the
   IPv6 allocation

"should also apply" or "also applies"

   A good practice is to have IPv6 reachability information carried over
   sessions established also on top of the IPv6 IP/TCP stack and
   independently of the IPv4 sessions.

clumsy wording, i had to read it twice to realize you meant "peer IPv4
SAFI information over IPv4 peers and IPv6 SAFI information over IPv6
peers", which is not the wording i'd suggest either..

   The Router-Server or Looking Glass external service should be
   available for external IPv6 access, either by an IPv6 enabled web
   page or an IPv6 enabled console server.

"route server"
s/external// as "external" and "internal" don't mean much here
".. an IPv6-enabled HTTP server and/or terminal reachable via TELNET or
SSH" with appropriate references to what those are

i don't know what section 6 is trying to accomplish. either make a full
blown list of what statistical and monitoring services IXPs should make
available or ignore the topic altogether. if there were serious
differences in those services between IPv4 and IPv6, it'd be worth
mentioning - but there really aren't. any protocol that has had a
refresh to support IPv6 would be appropriate, i suppose.

section 7: 
repeat: "it's important to market the fact [...]. Marketing is also important."
"and if possible via" ==> "and, if possible, via"
"If the website [...]" ==> "Along with ASN and IPv4 address(es), list
  participants' IPv6 address(es) in the membership roster."
"ASN's" => "ASNs"

section 8:
s/as was already mentioned// -- it's either worth mentioning again, or
it's not. no need to dwell on that.
s/reduced to/limited to/
"ICMPv6 neighbor discovery" => "ICMPv6 Neighbor Discovery"
"could be monitored" => "should be monitored"
"bad behaviors or configured problems" like what? enumerate these.
"This traffic" => "The link-local multicast traffic on this link"
"RFC 4861 [RFC4861]" => "[RFC4861]"

section 11, The author should refer to himself as "The author"

-- bill