Subject: [v6ops] comments on draft-ietf-v6ops-6to4-to-historic-08

From: Keith Moore <[email-masked]>
Date: Sat, 15 Nov 2014 22:45:26 -0500

In general, I support this version of the document.

I recommend several minor fixes listed below, mostly for clarity.

Abstract: delete the first sentence.

(in general, try to make the document refer precisely to RFC 3068, for 
improved precision/ clarity.)

Introduction:

- Delete the first sentence.  3056 is widely deployed as evidenced by 
its support in numerous operating systems and some routers. (either that 
or change "deployment" to "use")

- Penultimate paragraph:  recommend deleting this as I think it's 
misleading/confusing.  Though 6rd and 6to4 both use protocol 41, the two 
transition mechanisms have very different use cases, and are 
more-or-less orthogonal to one another.

- Last paragraph/sentence:  recommend it be changed to something like:

"Though there is currently no recommended drop-in replacement which 
serves the same use cases as 6to4, due to the exhaustion of IPv4 address 
space and consequent use of carrier-side NAT, the IETF sees no 
evolutionary future for the 6to4 mechanism."

(i.e. 6rd is not a replacement for 6to4, and there is really no good 
replacement for 6to4 yet, but 6to4 is nevertheless doomed.)

Section 3:

- end of 3rd paragraph: "has seen no deployment in the public 
Internet".   Is there any support for this statement?   If not, suggest 
removing it.  (Note that no observed use is not the same as no deployment.)

- 3rd bullet in "list of known issues":  this is true for a relay at a 
v4 anycast address, but not true for 6to4 relays in general. Suggest 
rewording to:

       There is generally no customer relationship between the end-user
       and the relay operator.   When using an RFC 3068 relay that listens to an
       anycast address, there is no good way for the end-user to know who
       the relay operator is, so no support is possible.

Section 4:

- 5th paragraph: "Internet service providers SHOULD filter out routes to 
192.88.99.1."   I think that should only apply to routes to other 
networks; I see no particular reason that providers that are currently 
providing 6to4 relays to their own customers should disable those relays 
or block their internal routing.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Nov 2014 19:01:48 +1300

Thanks Keith. Since I understand that Fred's robot will be
issuing a WGLC shortly, we will process these comments along
with WGLC comments.

Regards
   Brian

On 16/11/2014 16:45, Keith Moore wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>