Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

From: Ray Hunter <[email-masked]>
Date: Tue, 26 Apr 2011 21:57:59 +0200

RE: obsoleting RFC 3056 via draft-ietf-v6ops-6to4-to-historic-00

Would marking RFC3056 6to4 as "historic" as per the proposed text have 
any negative knock-on consequences for 6rd?

RFC 5969 quote "builds on 6to4 [RFC3056 
<http://tools.ietf.org/html/rfc3056>]" and refers to improvements of the 
6to4 mechanisms.

2nd Quote from RFC 5659: "6rd utilizes the same encapsulation and base 
mechanism as 6to4 and could be viewed as a superset of 6to4"

That would certainly be undesirable IMHO, as 6rd is one of the few 
transition mechanisms that seems to be scalable and explicitly designed 
with the aim of delivering a reliable and managed native IPv6 service as 
quickly as possible to end users.

Just asking as a naive end user.

regards,

---

From: Erik Kline <[email-masked]>
Date: Wed, 27 Apr 2011 08:55:56 +0900

would it suffice if 6rd were to refer to 4213 instead?  i think much
of what it really needs is actually there.  but perhaps there's
something it currently only gets from 3056.  :/

---

From: Mark Townsley <[email-masked]>
Date: Wed, 27 Apr 2011 08:36:51 +0200

Given we cannot change the text in RFC5969 without a full rev of the document, perhaps we should make it clear in the 6to4-historic document that while 6rd was based on 6to4, it does not share the same problems leading us to make 6to4 historic and why. 

- Mark

On Apr 27, 2011, at 1:55 AM, Erik Kline wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Apr 2011 08:50:07 +0200

> something it currently only gets from 3056.  :/
That's exactly what I'm wondering, myself. Which is why I asked in 
question form whether anyone would find this a problem.

I read RFC5969 once again and I find it difficult to put my finger on 
anything that will directly break.

So what does 6rd actually really inherit from 6to4 via RFC3056?
As opposed to general methods, and inherited references.

p1 lots of intro text
looks harmless enough

p2 the anycast failover references RFC3068, which in turn references RFC3056
Could be an issue? 
http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00 also 
move RFC 3068 to historic.

p2 reference to being a superset of 6to4
harmless text?

p2 6to4 could be achieved by setting the 6rd prefix to 2002::/16
Clearly that wouldn't be desirable any more, but wouldn't break 6to4.

p11: encapsulation as in [RFC4213 <http://tools.ietf.org/html/rfc4213>], 
which is the same mechanism used by 6to4 [RFC3056 
<http://tools.ietf.org/html/rfc3056>].
so that looks safe enough, as it also names the original reference

p14 security discussion
compares and contrasts but does not rely on 6to4

p15 RFC3056 is named as a normative reference
p16 RFC3068 is named as a informative reference

So it all seems pretty indirect, apart from the use of anycast failover, 
which could be a problem.

But it's still not exactly clear to me even at a second read how people 
would interpret 6rd (with anycast failover) if the underlying normative 
and informative RFC has been marked historic.

So I guess the text of draft-troan-v6ops-6to4-to-historic-00 could 
include some clarification that although 6to4 itself is considered 
historic, 6rd is most certainly not.

Best regards,
RayH

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Apr 2011 09:26:45 +0200

Ray,

I don't think there is any text in 5969 that can't stand on its own feet, even though 6to4 is deprecated.
5969 is the "fixed version of 6to4", so actually you could make the argument that 6to4 is superseded by 6rd.

I don't want to lose the historical reference. 6to4 invented the method of creating an IPv6 prefix based on an IPv4 address.

cheers,
Ole

> That's exactly what I'm wondering, myself. Which is why I asked in question form whether anyone would find this a problem.
> 
> I read RFC5969 once again and I find it difficult to put my finger on anything that will directly break.
> 
> Could be an issue? http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00 also move RFC 3068 to historic.
> 
> p11: encapsulation as in [RFC4213], which is the same mechanism used by 6to4 [RFC3056].
> So it all seems pretty indirect, apart from the use of anycast failover, which could be a problem.
> 
> But it's still not exactly clear to me even at a second read how people would interpret 6rd (with anycast failover) if the underlying normative and informative RFC has been marked historic.
> 
> So I guess the text of draft-troan-v6ops-6to4-to-historic-00 could include some clarification that although 6to4 itself is considered historic, 6rd is most certainly not.
> 
> Best regards,
> RayH

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Apr 2011 21:10:39 +0200

I obviously defer to you as the co-author of RFC5969.

Would it be possible to include some text in your proposal to clarify 
and encapsulate this view?

  e.g.

"Historic Links between 6rd and 6to4

Although 6rd has significant historic links with 6to4 (especially 
because 6to4 invented the underlying method of creating an IPv6 prefix 
based on an IPv4 address), 6rd was defined and improved in such ways 
that it does not share the same shortcomings for which the 6to4 
transition mechanism is being moved to historic status. Furthermore, the 
definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and 
RFC3068 that 6rd may be considered as a stand alone protocol in and of 
itself, independent of 6to4."

---

From: Ole Troan <[email-masked]>
Date: Wed, 27 Apr 2011 21:27:44 +0200

Ray,

> Would it be possible to include some text in your proposal to clarify and encapsulate this view?
> 
>  e.g.
> 
> Although 6rd has significant historic links with 6to4 (especially because 6to4 invented the underlying method of creating an IPv6 prefix based on an IPv4 address), 6rd was defined and improved in such ways that it does not share the same shortcomings for which the 6to4 transition mechanism is being moved to historic status. Furthermore, the definition of 6rd in RFC5969 is sufficiently decoupled from RFC3056 and RFC3068 that 6rd may be considered as a stand alone protocol in and of itself, independent of 6to4."

revision 01 now has the following:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-01

   6rd [RFC5969] utilizes the same encapsulation and base mechanism as
   6to4, and could be viewed as a superset of 6to4 (6to4 could be
   achieved by setting the 6rd prefix to 2002::/16).  However, the
   deployment model is such that 6rd can avoid the problems described
   here.  In this sense, 6rd can be viewed as superseding 6to4 as
   described in section 4.2.4 of [RFC2026]

is that better?

cheers,
Ole

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Apr 2011 21:38:03 +0200

Yes, that's clear to me thanks. I think that also improves the overall 
proposal, which is obviously the prime objective.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Apr 2011 09:02:35 +1200

>    described in section 4.2.4 of [RFC2026]

Works for me. Also, there is no formal problem with RFC 5969 citing RFC 3056
even if the latter is made Historic. (It would be a wordsmithing problem if
RFC 5969 was to be updated.)

BTW, Section 5 of draft-ietf-v6ops-6to4-advisory also mentions this
topic briefly.

   Brian