Subject: Re: [74attendees] The great emphasis on IPv6 - a positive look

From: james woodyatt <[email-masked]>
Date: Wed, 25 Mar 2009 09:05:36 -0700

[moving discussion into V6OPS from 74attendees]

On Mar 25, 2009, at 08:03, Rémi Després wrote:
>
> RFC 3068 (An Anycast Prefix for 6to4 Relay Routers) does more harm  
> than good. IMHO, it should be deprecated.

I would support that, providing first that 6RD is A) adopted as a  
proposed standard, and B) comes to see more widespread deployment than  
6to4.  I also believe the latter is very likely to happen contingent  
on the former, so I would vigorously support taking up 6RD as a  
working group activity.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Mar 2009 09:18:40 -0700

On Mar 25, 2009, at 9:05 AM, james woodyatt wrote:

> proposed standard, and B) comes to see more widespread deployment  
> than 6to4.  I also believe the latter is very likely to happen  
> contingent on the former, so I would vigorously support taking up  
> 6RD as a working group activity.

6rd is a transition behavior. Please refer to http://www.ietf.org/html.charters/v6ops-charter.html 
, and its two statements regarding working group effort on transition  
behaviors.

IPv6 Operations, in this context, can generate requirements. Our ADs  
have told us to ask other working groups to build solutions when  
solutions are needed. This has not stopped folks from asking for slots  
to discuss transition behaviors, and I have been lenient in allowing  
that. That doesn't allow us to take it up as a working group focus.

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Mar 2009 09:18:08 -0700

> on the former, so I would vigorously support taking up 6RD as a 
Excellent.

At 4:00 PM today at IETF registration, I will meet Benoit Lourdelet and 
Richard Johnson to propose a 6rd DHCP option.
(You are obviously welcome if you would like to join.)

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2009 05:46:19 +1300

> [moving discussion into V6OPS from 74attendees]

[and dropping 74attendees]

> 6to4.  I also believe the latter is very likely to happen contingent on
> the former, so I would vigorously support taking up 6RD as a working
> group activity.

Firstly, I think 6RD is worthy of consideration, although I'm not sure
it should be here rather than 6MAN or even individual submission to
an AD.

Secondly, I think it's quite premature to deprecate the 6to4 anycast
method. Of course, I would have preferred to see 6to4 deployed as
described in RFC3056 (i.e. relay addresses would be specific unicast
addresses) but we can't put the toothpaste back in the tube at this
point. In a few years 6to4 should fade away spontaneously. Meanwhile
we need to live with it, e.g. draft-nward-6to4-qualification.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 Mar 2009 09:55:59 -0700

On Mar 25, 2009, at 09:18, Fred Baker wrote:
> , and its two statements regarding working group effort on  
> transition behaviors.
>
> solutions are needed. This has not stopped folks from asking for  
> slots to discuss transition behaviors, and I have been lenient in  
> allowing that. That doesn't allow us to take it up as a working  
> group focus.

Ooops!  My mistake.  Since 6RD is a tunneling mechanism and not a  
translating mechanism, I would expect this request should be directed  
to SOFTWIRE.  So, here I am in SOFTWIRE now.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 25 Mar 2009 19:16:23 +0200

> on the former, so I would vigorously support taking up 6RD as a

Anycast 6to4 has problems. I guess Nathan Ward will present some of those. 6RD 
solves many of the shortcomings of 6to4, _assuming_the_ISP_deploys_it_.

But lest we deprecate the entire scenario of automatic IPv6 setup without ISP 
support, I fail to see how 6RD can replace anycast 6to4.

-- 
Rémi Denis-Courmont

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 25 Mar 2009 19:20:20 +0200

> (You are obviously welcome if you would like to join.)

A large subset of what I assume are potential target deployments for 6RD does 
NOT use DHCP. PPP(|oA|oE) IPCP comes to mind. Not to mention non-IETF 
protocols such as PDP.

-- 
Rémi Denis-Courmont

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Mar 2009 10:45:38 -0700

Rémi Denis-Courmont  -  le (m/j/a) 3/25/09 10:20 AM:

Excellent.

1. It's by mistake that I sent info on the planned meeting on the v6ops
list.

Apologies to all for this.

2. IMHO, the fact that other mechanisms than DHCP, PPP etc., may also
take advantage of a 6rd option is not a reason why progress on DHCP
should be slowed down, right?

Which subset of the potential target one starts with can be considered
a minor question.

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Mar 2009 12:25:15 -0700

Rémi Denis-Courmont  -  le (m/j/a) 3/25/09 10:16 AM:

Thanks for your comment.

Using 6to4 between two 6to4 user sites is NOT a problem, and indeed
MUST remain possible.

But using a source 6to4 address to reach a non-6to4 destination IS a
problem, and IMHO MUST be deprecated ASAP.

6to4 to non-6to4 being the only reason for 6to4 relay routers, and for
the 6to4 anycast address to reach them, they are what needs being
deprecated.

I guess RFC 3484 should also be updated to say that a 6to4 address MAY
be used if both source and destination are 6to4, but ONLY in this case.

Regards,

RD

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 25 Mar 2009 22:41:57 +0200

On Wednesday 25 March 2009 21:25:15 Rémi Després wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
...
> MUST remain possible.<br>
> problem, and IMHO MUST be deprecated ASAP.<br>

I am using Anycast 6to4 at home and it worksforme(tm). Who is going to be my 
6RD endpoint when 6to4 is deprecated? My ISP does not provide 6RD. I don't 
know if ny DOCSIS modem is compatible with 6RD, and I know for sure that my 
CPE does not implement 6RD.

6RD is NOT an alternative to 6to4. 6RD is an alternative to native IPv6 for 
access networks. To put it another way, 6to4 is deployed by end sites, whereas  
6RD is deployed by access providers.

Also IMHO, splitting the IPv6 Internet is a worse idea than keeping 6to4.

> <br>
> deprecated.<br>
> <br>
> be used if both source and destination are 6to4, but ONLY in this case.<br>

I do not believe we can update the millions of RFC3484-capable nodes in the 
wold, in the expected time frame for 6to4.

-- 
Rémi Denis-Courmont

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2009 10:23:28 +1300

On 2009-03-26 08:25, Rémi Després wrote:
> Using 6to4 between two 6to4 user sites is NOT a problem, and indeed MUST remain 
> possible.
> But using a source 6to4 address to reach a non-6to4 destination IS a problem, 
> and IMHO MUST be deprecated ASAP.

I'm sorry but this makes no sense. 6to4 users (they exist) need to
reach the IPv6 Internet, and a 6to4 relay is the only way to do that,
so they have to exist too. Otherwise we are creating IPv6 islands, which
is a bad idea for encouraging adoption.

The fact that the anycast technique leads to black holes is well known;
I've been a victim of it myself. I'd be much happier if 6to4 had been
deployed as described in RFC3056, but we have to deal with reality.
Once again, see draft-nward-6to4-qualification for one way to
do that.

> 
> 6to4 to non-6to4 being the only reason for 6to4 relay routers, and for the 6to4 
> anycast address to reach them, they are what needs being deprecated.
> 
> I guess RFC 3484 should also be updated to say that a 6to4 address MAY be used 
> if both source and destination are 6to4, but ONLY in this case.

Absolutely not. That would make the black hole problem global instead of
localised. 6to4 was given its own /8 global prefix so that longest match
would do the right thing, within the scope of the 3484 rules. (Yes,
3484 was published after 3056, but there was coordination.)

    Brian

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Mar 2009 15:01:21 -0700

Brian E Carpenter  -  le (m/j/a) 3/25/09 2:23 PM:

Thanks for your comment.

Agreed (a partial backtrack): if a 6to4 host first checks that it has a
return path from a native v6 site, then it may proceed rather than
giving up v6 and falling back to v4.

Note however that, for still some time, falling back to v4 when the
quality of v6 paths is not guaranteed is not a bad choice.

Note also that Nathan's proposal checks only connectivity. Uncertainty
on QoS remains, due to the lack of control on which 6to4 relay routers
are used in return paths.

localised.

In my understanding, backing up to v4 when v6 is not fully reliable
doesn't create  black holes. It prevents them.

At least where 6to4 qualification is not available yet (and substantial
host modifications don't come overnight), avoiding 6to4 to non-6to4
remains IMHO a good way to avoid people to be disappointed with IPv6
and complain.

Regards,

RD

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 26 Mar 2009 07:50:52 +0900

> Also IMHO, splitting the IPv6 Internet is a worse idea than keeping  

Ditto.

My 6to4 router at home works fine for me and my family.
However, the problem is that 6to4 is preferred than IPv4
and Japan does not have 6to4 relay router until very recently,
so sometimes my packets have to go back and force pacific
ocean to connect an dual-stack server in my office.

The problem of mine can be solved by switching preferences
of ipv4 and 6to4. And some people that advocate deprecating
6to4 here seem to be able to live with this trivial change.

Of course, you may say that IPv6 address, including 6to4,
should be preferred for the sake of NAT unfriendly
applications, but it is not worse than losing 6to4.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2009 11:59:57 +1300

Rémis, and all,

Just to summarize for the group a coffee conversation
with Rémi D and Keith Moore, one possible way forward
is a new document describing best (and worst) practice for
6to4 relay deployment, and associated 6to4 host behaviour.

    Brian

On 2009-03-26 11:01, Rémi Després wrote:
> Agreed (a partial backtrack): if a 6to4 host first checks that it has a return 
> path from a native v6 site, then it may proceed rather than giving up v6 and 
> falling back to v4.
> 
> Note however that, for still some time, falling back to v4 when the quality of 
> v6 paths is not guaranteed is not a bad choice.
> Note also that Nathan's proposal checks only connectivity. Uncertainty on QoS 
> remains, due to the lack of control on which 6to4 relay routers are used in 
> return paths.
> 
> In my understanding, backing up to v4 when v6 is not fully reliable doesn't 
> create  black holes. It prevents them.
> At least where 6to4 qualification is not available yet (and substantial host 
> modifications don't come overnight), avoiding 6to4 to non-6to4 remains IMHO a 
> good way to avoid people to be disappointed with IPv6 and complain.
> 
> Regards,
> 
> RD

---

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Mar 2009 18:42:59 -0700

As Brian kept mentioning this draft and encouraged us to review it, I just did.

Nathan's draft proposes to verify 6to4 connectivity before configuring the 6to4 interface. The verification proceeds in two steps. First, verify that a well known IPv6 6to4 address is reachable over 6to4, by means of a ping test. Then, verify that a well known native IPv6 address is reachable through the default 6to4 relays, again by doing a ping test. If these two test succeed, the interface is qualified and routes are installed.

This verification is a good idea. There is no point in configuring 6to4 if it does not work, especially if other technologies like Teredo could be used, or if remedial steps could be taken, like for example trying a different relay address. Nathan's draft addresses a real need, and I would like it to be adopted as a work item.

The draft is indeed in an initial proposal. I have several comments, some technical and some editorial. First, the two editorial comments:

* The procedures can be summarized in a single paragraph. The draft would be easier to understand if the abstract included such a summary.

* The draft uses place holder acronyms like TBD, TBD1, TBD2. I suggest giving actual names to these variables, e.g. "the 6to4 connectivity test address", and explaining the names in a "notations" section at the beginning of the draft.

Now, the technical comments:

* the draft instructs IANA to allocate a 24 bit IPv4 prefix. Good luck with that. I suggest considering a design that does not carry this requirement.

* the draft requests configuration of both a 6to4 address (TBD1(6to4)) and the corresponding IPv4 address (TBD1(IPv4)). It would be simpler to just configure a 6to4 address, and algorithmically extract the IPv4 address from that 6to4 address.

* The draft assumes that the tests are conducted using two well known IPv6 addresses. These addresses are likely to receive a lot of traffic. Since the draft attempts to cure issues caused by the use of anycast addresses, I presume we do not expect to use anycast for load sharing. How then do we expect to sustain the load, and provide adequate reliability?

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 Mar 2009 19:11:08 +1030

Hi,

On Wed, 25 Mar 2009 22:41:57 +0200

> 6RD is deployed by access providers.

I agree with Remi, 6RD isn't a functionally equivalent alternative to
6to4.

Here in .au ADSL routers are owned by the customer, not managed
by the ISP, so deploying IPv6 via 6RD is unfortunately not an option.

Regards,
Mark.

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 26 Mar 2009 10:12:42 +0100 (CET)

> I agree with Remi, 6RD isn't a functionally equivalent alternative to

The most important difference is that 6RD forcing to the provider to 
provision their own relay.

> by the ISP, so deploying IPv6 via 6RD is unfortunately not an option.

As most of the case in the world. Usually the DSL modem owned by the 
provider, but not the router. But there are some countries you can own 
your own DSL modem. In the DOCSIS architecture the cable modem, always 
owned by the provider, potentially can be made more smart to support 6RD, 
however most of the user already installed dumb soho router without ipv6 
support.

Best Regards,
 		Janos Mohacsi

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 26 Mar 2009 10:45:13 +0100

Rémi Després wrote:
[..]
> Using 6to4 between two 6to4 user sites is NOT a problem, and indeed MUST
> remain possible.

I full agree with this.

> be used if both source and destination are 6to4, but ONLY in this case.

The idea of 6to4 is great and it also works pretty nifty in practice.

The idea of 6to4+anycast was also good, but unfortunately one gets
several layers of BGP-pull and misconfiguration which are very hard to
debug and thus solve, especially as one will never have access to all
nodes in both IPv4 and IPv6 paths, both ways, to correctly debug it.
On a controlled network that works, but on the wide internet this
doesn't and only causes a lot of issues.

I have to state though that there are a LOT of happy 6to4 users, but
they are only accessing more or less local resources. Thus network-wise
not too far away, which thus makes it a more or less controlled environment.

Greets,
 Jeroen

---

From: Jeff McAdams <[email-masked]>
Date: Thu, 26 Mar 2009 07:34:07 -0400

> provision their own relay.

Except that it doesn't.

This is a little bit of semantics on the surface, but there's a very 
real point behind it.

Many ISPs don't care about supporting IPv6 yet.  If you, as a customer, 
call their support line to task about it, you basically get something 
along the lines of, "What's IPv6?  Have you rebooted your Windows and 
your (cable|DSL) modem?"

If ISPs don't care enough to support, or even have an inkling of IPv6, 
they're also not going to deploy anything like 6RD (though I admit I'm 
just picking up on the 6RD conversation...but if it requires ISPs to 
deploy something, its basically dead in the water for a long time still).

There are many people (myself included) that are happily using 6to4, and 
we're using 6to4 because the ISPs available to us are utterly and 
completely clueless, so we don't really have any other option.  If the 
6to4 anycast goes away and you require the ISP to deploy something for 
the replacement technology, you are effectively cutting us off from the 
IPv6 Internet for the foreseeable future.  The only other option I see 
is hard to manage and configure, and frequently bandwidth constrained, 
tunnel brokers.

Oh, and my CPE supports 6to4, but not a tunnel broker sort of setup (at 
least that I can find...Apple Airport Extreme)

I don't have any problem with 6RD as an additional transition 
mechanism...I'm not sure its worth the effort, but if people want to go 
down that path, then that's their choice...but please don't take away 
6to4 anycast gateway or I, and several households that I work with, go 
away from the IPv6 Internet.

> owned by the provider, potentially can be made more smart to support 
> 6RD, however most of the user already installed dumb soho router without 
> ipv6 support.
> 
> Best Regards,
>         Janos Mohacsi

-- 
Jeff McAdams
[email-masked]

---

From: Rémi Després <[email-masked]>
Date: Thu, 26 Mar 2009 08:11:02 -0700

Jeroen Massar  -  le (m/j/a) 3/26/09 2:45 AM:

Rémi Després wrote:
[..]

I full agree with this.

If they do 6to4 to 6to4, which I suppose should often be the case so
far, they are quite right to be happy. They have a good service.

And this will remain so as long as they don't try to do 6to4 to non
6to4 without checking first that a path exists, which current OS don't
do.

Even if connectivity is checked, the QoS of the 6to4 relay router they
happen to have used is in general not guaranteed, so that backing up to
IPv4 may in general be safer. (This problem doesn't exist with 6rd.)

Regards,

RD

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 26 Mar 2009 16:41:43 +0100

Rémi Després wrote:
[..]
> And this will remain so as long as they don't try to do 6to4 to non 6to4
> without checking first that a path exists, which current OS don't do.

Indeed. Though there are lots of users also happily using
anycasted-6to4. The reason being that the services they are using from
their 6to4 address are located at ISPs that are either clueful and
pro-active in fixing issues or that they are located closely to the
relay which is their anycast node. In that case one basically has an
automatically set-up proto-41 tunnel directly to the service you are
using, and then things work quite smoothly.

The moment though that other networks, who did setup 6to4 but who don't
really check their service get involved, then things start to break
miraculously. And as a content-provider on native IPv6 there is not much
to do about those kind of networks, but they do affect connectivity to
the enduser.

> IPv4 may in general be safer. (This problem doesn't exist with 6rd.)

Well it doesn't exist in 6rd because then the infrastructure is all ISP
owned and most likely they do care about their network.

Note that 'checking connectivity' is not always a good thing, especially
when one is checking connectivity to a well-maintained service, that one
might work, but any other network will just still fail.

Greets,
 Jeroen

---

From: Rémi Després <[email-masked]>
Date: Thu, 26 Mar 2009 08:55:19 -0700

Jeff McAdams  -  le (m/j/a) 3/26/09 4:34 AM:
> Many ISPs don't care about supporting IPv6 yet.  If you, as a 
> customer, call their support line to task about it, you basically get 
> something along the lines of, "What's IPv6?  Have you rebooted your 
> Windows and your (cable|DSL) modem?"
>
When you read draft-despres-6rd-02, you will see that Free, the second 
largest ISP in France, with millions os DSL customers, deployed 6rd in 5 
weeks (6rd stands for IPv6 Rapid Deployment.)
>
> There are many people (myself included) that are happily using 6to4, 
> and we're using 6to4 because the ISPs available to us are utterly and 
> the replacement technology, you are effectively cutting us off from 
> the IPv6 Internet for the foreseeable future.
The point is that ISPs, rather than setting up a 6to4 relay router 
should setup a 6rd Gateway in order to offer native IPv6 prefix to their 
customers.
>   The only other option I see is hard to manage and configure, and 
> frequently bandwidth constrained, tunnel brokers.
>
> Oh, and my CPE supports 6to4, but not a tunnel broker sort of setup 
> (at least that I can find...Apple Airport Extreme)
>
> mechanism...I'm not sure its worth the effort, but if people want to 
> go down that path, then that's their choice...but please don't take 
> away 6to4 anycast gateway or I, and several households that I work 
> with, go away from the IPv6 Internet.
Taking them away is not needed. It's only that using them without 
precautions to reach native IPv6 servers will lead to customer 
frustration with, at least sometimes, poor quality IPv6 experience, 
something to be avoided.

Regards,

RD

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Mar 2009 09:40:08 -0700

> From: Jeroen Massar, Thursday, March 26, 2009 8:42 AM

> Indeed. Though there are lots of users also happily using anycasted-
> 6to4. The reason being that the services they are using from their 6to4
> address are located at ISPs that are either clueful and pro-active in
> fixing issues or that they are located closely to the relay which is
> their anycast node. In that case one basically has an automatically
> set-up proto-41 tunnel directly to the service you are using, and then
> things work quite smoothly.
>
> miraculously. And as a content-provider on native IPv6 there is not
> much to do about those kind of networks, but they do affect
> connectivity to the enduser.

Jeroen gives a good description of the problem. Anycast is convenient, but unpredictable. In theory, anycast allows 6to4 nodes to always use the relay closest to them, which should provide for a good service. In practice, that works well when the relay is actually close, e.g. managed by the local provider, but not so well when the relay is remote and the route to it obtained through several BGP hops.

There are several possible mitigations to this issue.

An obvious mitigation is, "deploy more relays." The hope when writing RFC 3068 was that many providers would deploy many relays for local use, and thus users would be mostly be using local relays. When there are many relays, the reliance on BGP is minimal, and the service becomes much more reliable. Of course, I realize that if the IETF recommend deploying more relays, providers may or may not follow the recommendation. The cost of deploying relays is not very high, but the benefits are also not very high, essentially a slight reduction in the amount of tunneled traffic through the providers interconnections and probably also a slight reduction in the number of support calls. Even so, clear messages from the IETF would certainly help.

Another mitigation is to "avoid 6to4 when it does not work" -- and presumably use another technology in these cases. This is the approach documented in Nathan Ward's draft. It makes a lot of sense from an operational point of view, but it requires that the end systems implement test procedures. This will probably happen over time. On the other hand, if we consider updating end system, we can also consider changes to end system that increase the reliability of 6to4.

Since RFC 3068 was published, there have been several suggestions for improvements. One possibility is to explicitly provision a 6to4 gateway in the 6to4 node. This is obviously a tradeoff, as sending traffic to a remote gateway may be less efficient than sending traffic to the closest anycast gateway -- but it is also much more predictable. An interesting possibility would be to combine this provisioning with the test procedure, maybe testing several gateways and selecting the one that works best.

-- Christian Huitema

---

From: Jeff McAdams <[email-masked]>
Date: Thu, 26 Mar 2009 12:56:41 -0400

> weeks (6rd stands for IPv6 Rapid Deployment.)

And that's great for them.  Seriously, I applaud them for that.  But my 
comment was about ISPs that just flat-out don't care.  At all.  In the 
slightest.  And sadly, this is a significant fraction of the consumer ISPs.

Free, in France, clearly cares about IPv6 and wants to deploy it in the 
most reliable and effective way possible.  Again, I applaud that 
wholeheartedly.  Let me know when Windstream, here in the US responds to 
questions about IPv6 with anything other than, "Have you rebooted your 
computer and DSL modem?"

Earlier in the thread, there was discussion of taking away anycast 6to4 
gateways.  That's the only thing that I'm against, here.  If you and 
others want to deploy 6RD, fantastic, more power to you.  If Windstream 
deploys 6RD, I'll try to take advantage of it as well...I'm definitely 
not holding my breath that they will, though.

In the meantime, without 6to4 anycast relays, my only other option for 
IPv6 connectivity is harder-to-manage-and-configure tunnel broker 
connections.  Realistically, removing 6to4 anycast relays cuts me off 
from the IPv6 Internet.

> frustration with, at least sometimes, poor quality IPv6 experience, 

I haven't experienced any significant negative behaviors from 6to4 
anycast relays.  I know that its possible, and troubleshooting that case 
is hard, very hard even.  Its uncommon enough, in my experience at 
least, that 6to4 is a reasonable, if not perfect, transition mechanism 
for use on an ISP that just is utterly clueless that the Internet is 
anything more than HTTP on port 80 and 443 (as far as I know, 
Windstream's email infrastructure is webmail only...*sheesh*)

All I'm asking for is to not deprecate 6to4 anycast relays as part of 
6RD.  Using 6RD looks like (after a quick perusal of the 
draft...certainly don't qualify as an expert on it) a reasonable 
improvement as a transition mechanism, at least in networks where the 
ISP wishes to support IPv6 access.  Just don't forget about us poor 
folks on the truly clueless ISPs that want to help push the IPv6 
adoption cause forward.
-- 
Jeff McAdams
[email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Sat, 28 Mar 2009 10:33:27 +0100

>should setup a 6rd Gateway in order to offer native IPv6 prefix to their 

I wonder, what if ISPs who want to do an '6rd' like thing would announce
longer prefixes than just 2002::/16. For example an ISP who has customers
in an IPv4 /16 can announce 2002:xxyy::/32.

To me it seems like that would end the 2002::/16 blackhole problem for that
ISP's customers.

Philip Homburg

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 28 Mar 2009 11:38:42 +0100

> To me it seems like that would end the 2002::/16 blackhole problem for that

And import the complete IPv4 routing table into the IPv6 routing table.
No thank you.

See the 6to4 RFC btw which discusses that.

Fortunately 2002::/16 orlonger is pretty well filtered.

Greets,
 Jeroen

---

From: Philip Homburg <[email-masked]>
Date: Sat, 28 Mar 2009 15:48:32 +0100

>And import the complete IPv4 routing table into the IPv6 routing table.

No, instead of that, every ISP gets a completely new prefix, wastes a lot of
bits in that prefix (you need 32 bits for the IPv4 address),
and then adds it to the routing table. And you can't even give customers
the /48 they are supposed to get.

>Fortunately 2002::/16 orlonger is pretty well filtered.

You are saying that if an ISP gets a /32 from a RIR it is no problem, but a
2002::xxyy/32 suddenly is a problem?

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 28 Mar 2009 16:27:27 +0100

> bits in that prefix (you need 32 bits for the IPv4 address),

6rd does NOT require that. Did you read Remi's draft? If an ISP has a
IPv4 /21 for their customers they want to IPv6 enable then they need
32-21 = 11 bits. Thus they need a /48 - 11 = /37 for their 6rd prefix.
Then every user gets a nice /48. Or what Free does, give a /56 which is
'good enough for endusers' and thus you only need a /56 - 11 = /45.
If they ISP has 5 IPv4 /21s they thus need 5x /45 for this trick.

That address space can later, when the users get real native v6 (if
ever) be re-allocated for other things.

Still only 1 /32 (or larger if the ISP was able to justify that) will be
visible in the IPv6 routing tables. Instead of 5 6to4 prefixes which
should not be there in the first place.

> 2002::xxyy/32 suddenly is a problem?

Yes, as that is what the RFC specifies. As I wrote in my previous email
(and thus still a few lines above here) to avoid importing the IPv4
routing tables into IPv6. IPv6 != IPv4.

Please actually read the 6to4 RFC and the 6rd draft.

Greets,
 Jeroen

---

From: Jeff McAdams <[email-masked]>
Date: Sat, 28 Mar 2009 12:18:02 -0400

> 2002::xxyy/32 suddenly is a problem?

Yes, because 2002::xxyy/32 or whatever, as a direct import of the IPv4 
routes results in much more routing table explosion than an ISP getting 
a /32.

The ISP that I used to work for is relatively small and has to inject 7 
IPv4 routes into the DFZ.  When they go with IPv6 (alas, they haven't 
started that work yet, to my knowledge...I keep poking, though), they'll 
have 1 that will provide them with IPv6 space for pretty much any 
anticipated needs long long into the future.
-- 
Jeff McAdams
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Mar 2009 10:43:49 +1300

> anticipated needs long long into the future.

Of course. But as Jeroen said, please read RFC3056. The only more-specifics
under 2002::/8 that make any sense whatsoever are /48, and there would
*potentially* be about 300,000 of them today, one per announced IPv4 network.
More specifics under 2002::/8 are very much not allowed. Mr R. Bush gave
us a very hard time about that before RFC3056 was approved.

My point was that the same danger applies to a NAT64 well-known prefix.
unless we carefully avoid it.

    Brian

     Brian

---

From: Francis Dupont <[email-masked]>
Date: Tue, 31 Mar 2009 22:17:54 +0200

In your previous mail you wrote:

   *potentially* be about 300,000 of them today, one per announced IPv4 network
   
=> unfortunately if someone does it there is nothing we can do (no
Internet police :-). I am afraid one day we regret not have adopted
my proposal to reverse the bits of the embedded IPv4 address, a drastic
way to enforce no spurious injection of the IPv4 mess into the IPv6
routing table...

Regards

[email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 31 Mar 2009 22:37:31 +0200

> way to enforce no spurious injection of the IPv4 mess into the IPv6

That would have been a partial solution indeed that would have voided
any person from attempting to do so indeed ;)

Fortunately 2002::/16 is very well filtered. And people who do try that
one will be shot on site, thus this is a non-issue IMHO.

Greets,
 Jeroen