Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt>

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In message <000901cc270d$430ec000$6801a8c0@oemcomputer>, "Randy Presuhn" writes
:
> We can't compel people to continue supporting it any more than we can
> make them stop.  At most, we can give them (hopefully convincing) reasons
> to change.  If the SNMP experience shows anything, it shows that even
> that isn't enough.  For that reason, I find it amusing when others write of 
> "killing" 6to4.  We don't have that kind of power.

But you can give them a big excuse not to support it.

Customer: "Where did the 6to4 support go?"
Vendor: "The IETF declared it historic so we removed it."
Customer: "I was using it, can you put it back?"
Vendor: "I repeat the IETF declared it historic."

6to4 on by default is wrong. 

However if a user/site turns 6to4 on they do that with the full
knowledge that it will add delays and it does use third party relays.
As to those that say users won't accept 100ms delays many actually
will accept the delay and it does not impact on what they do. The
tunnel I use adds +300ms to some IPv6 sites compared to IPv4 but
unless I explicitly measure it I don't notice it.

Making 6to4 historic is a knee jerk reaction to a bad default setting.
Fix the default.  Don't make 6to4 historic.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]