Subject: (ngtrans) Re: draft-ietf-ngtrans-6to4-06.txt

From: Randy Bush <[email-masked]>
Date: Thu, 10 Aug 2000 11:33:45 -0700

folk generally like the approach and the document.  but, on the iesg
telechat today, the following issues were raised in respect to
draft-ietf-ngtrans-6to4-06.txt:

  o the title is too similar to rfc2529 

  o there needs to be a clear statement that

    - this is a temporary transition mechanism

    - that it has serious scaling problems due to routing table explosion,
      and hence should have some sort time or size limit placed on its
      use, and maybe have a recommendation that it be blocked [by isps]
      by some size or date

  o if this is not meant as long-term technology, should it be ps?  maybe
    a note or an applicability statement would help.

randy

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 12 Aug 2000 22:02:33 -0400

>     - this is a temporary transition mechanism

to me, transition by definition is temporary, at least in the ipv4-to-ipv6 
context.
so a "temporary transition" looks bizarre to me.

ipv4 to ipv6 transition mechanisms are temporary. when everything is 
converted to ipv6, then no more transition tools/standard/mechanisms is needed.

The only problem is finding the timeframe. I'm not sure if someone really 
want to estimate that and put here somewhere in a RFC... ;-))

>     - that it has serious scaling problems due to routing table explosion,

right.

>       use, and maybe have a recommendation that it be blocked [by isps]

date seems to me very difficult to estimate.
size is probably much better, and also is clearly related to the routing 
table explosion problem.
Say for example that max size = 50K routing table (about half of the 
current routing table).
then what happen around the 50000th:
  + who is going to decide who has the "right" to use 6to4 and who hasn't
  + how can we really know the number of 6to4 routers, where some networks 
can be up and down.
  + if we want (I don't but not sure of any other way to resolve this) a 
registry to handle those issues, then we are back on square one: i.e. 6to4 
is easy. registry is more difficult, so we kill 6to4.

>   o if this is not meant as long-term technology,

as said: to me, no transition is going to be long-term.

>should it be ps?  maybe

I think this is the only thing that can really be done in the RFC. size and 
date looks to me not really useful to define. An applicability statement 
saying that "this doesn't scale for the full internet and that other 
mechanisms must be deployed to replace 6to4 in the event of routing table 
explosion", seems to me the only real thing that we can add.

my 2 cents.

Marc.

>randy

Marc Blanchet
Viagénie inc.
tel: 418-656-9254
http://www.viagenie.qc.ca

----------------------------------------------------------
Normos (http://www.normos.org): Internet standards portal:
IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Aug 2000 19:37:29 -0700

> context.  so a "temporary transition" looks bizarre to me.

well, do tell us when you work it all out.

> is easy. registry is more difficult, so we kill 6to4.

does this tell us anything about whether this scheme should be recommended
for deployment or how it should be deployed?

but i suspect that folk are going to want a serious answer to this issue.
recommending deployment of things with unscoped scaling problems is losing
popularity.

> An applicability statement saying that "this doesn't scale for the full
> internet and that other mechanisms must be deployed to replace 6to4 in the
> event of routing table explosion", seems to me the only real thing that we
> can add.

if we intend this to be a proposed standard, it might help if we were more
specific about what the scaling issues are, how they can be anticipated, and
what might be done to ameliorate, bypass, or replace them.

randy

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Aug 2000 16:37:06 +0200

In your previous mail you wrote:

=> I'd like to get an applicability statement too. Obviously
6to4 (as other transition mechanisms) has a narrow applicability space,
for instance it is not useful for ISPs (they'd prefer configured (ie.
managed) tunnels) nor home users (because of the dynamic IPv4 address).

Regards

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Aug 2000 10:18:03 -0500

Randy,

>   o the title is too similar to rfc2529

Not surprising really, for various reasons such as it is
a very similar idea (i.e. treat IPv4 as the link layer).
Is this a definite request for a cosmetic change? What change
would be acceptable?

>     - this is a temporary transition mechanism

As others have said, it's a transition mechanism. It seems entirely
redundant to say that it's temporary, but I can do it if it makes
someone happy.

>       use, ...

The scaling issue is supposed to be covered by the rules about advertizing
the 2002:: prefix, specifically section 5.2.2:

>    On its native IPv6 interface, the relay router MUST advertise a route
>    to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on
>    that interface. Routing policy within the native IPv6 routing domain
>    determines the scope of that advertisement, thereby limiting the
>    visibility of the relay router in that domain.

I'd like to understand why this leaves any scaling concerns, since it specifically
limits the number of IPv6 routing table entries to one.

>       ...and maybe have a recommendation that it be blocked [by isps]
>       by some size or date

I don't think it's the IETF's business to make such a recommendation, in fact
it would be unconscionable to do so and impossible to suggest a date.

>     a note or an applicability statement would help.

Yes, as the other transition techniques are PS. I can't see why a separate
applicability statement would help, but if somebody will make specific
suggestions we can add text in the introduction.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Mon, 14 Aug 2000 18:05:14 -0400

> managed) tunnels) nor home users (because of the dynamic IPv4 address).

home users do not necessarily have dynamic IPv4 addresses.

and 6to4 is somewhat useful even with dynamic IPv4 addresses.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Aug 2000 10:20:00 -0500

For the record...

> Randy Bush wrote:
...
> redundant to say that it's temporary, but I can do it if it makes

From the first paragraph of the introduction:

  "Also note that this is not considered
   to be a long term solution and that sites should migrate in due
   course to native IPv6 prefixes."

Section 5.6, Transition considerations, paragraphs 4 and 5, discuss 
the specific steps for migrating away from 6to4.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Aug 2000 14:53:25 -0500

Randy Bush wrote: (in response to Marc Blanchet)

> what might be done to ameliorate, bypass, or replace them.

The trouble is that 6to4 doesn't have any such scaling issues. It creates
exactly one routing native IPv6 routing entry and relay routers scale just as
well as any other tunnel end point or transit router solution. There's a specific
scaling issue in the scenario covered by Tony's draft, but that's out of scope
for the base document. The tweaks I am putting in this afternoon will
hopefully make this clearer.

  Brian