Subject: Re: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses"

From: Ole Troan <[email-masked]>
Date: Sun, 1 May 2011 11:49:46 +0200

Dmitry,

>>> Does the working group agree with the summarization of the concern? 
> 
> I agree the concern was summarized correctly.
> 
>>> Do we agree with the proposed action?
> 
> As I said in the quoted feedback, I don't think the action draft proposes is necessary to address the problem quoted, for the reasons listed below in the feedback summary. So I agree with the proposed action to change the text and I propose: to remove all the references about moving RFC 3056 to historic status from the draft, since in my opinion the draft doesn't state sufficient reasons for moving RFC 3056 to historic. Those of the listed problems, which are specific to 6to4, are addressed by the companion advisory and RFC 3484bis. Those which are not specific to 6to4, in my opinion, shall not be in the draft.

how does the advisory or rfc3484 address these problems:

>> Reply: Current text states:
>>       - Not deployed
>>       - Same problems as 3068 for the reverse path
>>       - Same problem with filtering
>>       - Not working with non-1918 addresses with topologically limited span

cheers,
Ole

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 2 May 2011 15:06:03 -0700

Hello Ole,

rfc3484 addresses them by making 6to4 one of the last resort interfaces. Advisory addresses by saying clearly it should not be on by default - so if someone enables 6to4, one has to assume they know what they are doing and what they are using it for.

Thanks,
Dmitry

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Sunday, May 01, 2011 2:50 AM
To: Dmitry Anipko
Cc: Fred Baker; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 3. "non-RFC1918 addresses"

Dmitry,

cheers,
Ole