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

From: Cameron Byrne <[email-masked]>
Date: Sun, 17 Apr 2011 16:22:26 -0700

As a network operator who currently null routes the 6to4 anycast since it
creates stale half opened sessions that will never work in my cgn,  I
support this draft and support 6to4 never being enabled by default.

Anycast 6to4 is not fit for what the internet has become or will be.

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 20 Apr 2011 08:06:50 -0700

On Apr 20, 2011 1:36 AM, "Mohacsi Janos" <[email-masked]> wrote:
>
>
>
>
> On Wed, 20 Apr 2011, Gunter Van de Velde (gvandeve) wrote:
>
>>
>> That depends on your role. From ISP perspective, 6to4 doesn't make a lot
of
>> sense. But for end users, sometimes a tunnel is all you can get.
Sometimes,
>> tunnels offer even a more complete IPv6 experience than native.
>>
>> GV> I guess you are speaking for the simple home-user. In that case what
limits a user from obtaining a managed commercial service for IPv6? That way
he gets at least SLA like commitments from his favourite services provider.
>>
>> GV> If its an enterprise there are better solutions out there that
deliver managed tunneling services.. pick your preferred vendor and they
will give you some options.
>
>
>
> In reality the situation slightly worse, let me cite our example:
>
> 1. NIIF/Hungarnet started to provide native IPv6 DSL service around 2008 -
we wanted to do it earlier, but due to a bug in DSLAM equipment stopped us
to provide it. Our LNS equipment was capable of handling DHCPv6-PD. We had
to wait the telecom operator (1.5 years) to fix the problem. As an interim
solution we started experimenting with 6to4 and Teredo. It was working
reasonably well.
>
> 2. After fixing the DSLAM bug in the provider network and deployment of
native IPv6 DSL service we considered switching 6to4 relay off. But there
was a demand from administrators of our users (Universities, Research
Institutes, Libraries) to let it run for further experimenting: There is
only one other provider started provide native IPv6 DSL. The two big DSL
player in Hungary is still testing and piloting their (for at least another
year) IPv6 DSL services.
>
> In my opinion tend to be similar to Jordi's. 6to4 is good for
experimenting with IPv6. If you need IPv6 service use native solution. But
if there no solution on the market what to do?
>
> According to our policy our 6to4 relay is only for experimenting with IPv6
technology..... What about 6to4 relabeled to experimental?

What good is this policy if the customer does not know they are using 6to4
because it is default on?

If the customer NEEDS ipv6 (I wish I had these customers, I don't) then
surely they would rather have a managed service like 6rd or ideally native

Cb

> Best Regards,
>                Janos Mohacsi
>
>
>
>
>>
>> G/
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ray Hunter <[email-masked]>
Date: Thu, 21 Apr 2011 09:45:53 +0200

[delurk]
I have been lurking for quite a while around various IPv6 lists, and 
trying to get up to speed with the very latest developments in IPv6, 
especially regarding suitable transition mechanisms, or more to the 
point, the danger these mechanisms pose as defaults in a managed 
migration in a corporate environment.

Hopefully I can add something positive to the debate.

RFC 1958 (informational) states "It is also generally felt that 
end-to-end functions can best be realised by end-to-end protocols."

Assumption 1: The only proven scalable solution that will facilitate 
long-term growth and stability of the Internet is to deploy native IPv6 
end to end.

Assumption 2: Transitional mechanisms may be useful in moving towards 
the end game of deploying native protocols end to end. They are a means 
to an end, and not a destination in themselves.

Assumption 3: Transitional mechanisms that are no longer useful can die 
a natural death. The IETF does not need to take any action on these, as 
the market will come to their own conclusion and take the desired 
actions themselves without any further intervention. However, 
transitional mechanisms that are actively preventing a further move 
towards deploying native end to end protocols could and should be 
clearly deprecated.

Assumption 4: 6to4 has not proven itself as a good transition mechanism 
as it is not widely used (no reason to deprecate).

Assumption 5: 6to4 may actually be preventing deployment of native IPv6 
(good reason to deprecate)

Assumption 6: I see text in 
http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic-00. 
stating that the protocol "6to4" is deprecated as well as the address 
"2002::/16"

I had to search for quite a while before I could find out what it 
actually meant for a protocol to be deprecated (as opposed for use of an 
IPV6 address to be deprecated, which is clearly defined in the existing 
RFC3484).

The mechanism suggested for actually implementing the deprecation seems 
to be via amending the source and destination address selection 
mechanism as defined in RFC3484 and proposed to be amended as in 
http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 . However, 
this is only a recommendation for a default policy table, and people may 
not have used this particular table in their implementations. It is also 
unclear how often people will update their local policy table on their 
local host.

To me, deprecating use of a protocol, and suggesting it should only be 
used as a protocol of "last resort" are two different things. If you 
deprecate a protocol, it shouldn't be used any more.

Assumption 7: Since the mechanism for implementing deprecation will 
certainly be implemented on a per host basis, there is a clear danger 
that if the implementation of the choice of 6to4 as a "last resort" 
protocol as suggested in the revised RFC3484 policy table is not widely 
synchronized, that when a node A contacts host B it will use protocol X, 
but when host B contacts host A it will use protocol Y.

Assumption 8: Asymmetric protocol use is an extremely undesirable 
phenomenon that could actually make matters far worse operationally than 
a single not-so-great protocol communicating in both directions.

Assumption 9: Deprecation of a transitional mechanism should not lead to 
an extended period where the implementation of the deprecation may 
actually make the Internet worse operationally.

My opinion: There needs to be a clear motivation for why 6to4 is 
actively preventing 6to4 roll out. I think this clear motivation is 
somewhat lacking in the current text. The current focus, the way I read 
it, is on why 6to4 isn't a great protocol, rather a clear description of 
why 6to4 is actively preventing native IPv6 roll out. There also needs 
to be a clear end date for implementation of the deprecation, to avoid a 
transition on a transition.

So I can't agree with the text as-is.

But I would suggest that the authors amend the text so that it:
i) better motivates that use of 6to4 is actively preventing roll out of 
native IPv6
ii) includes a clear date for full deprecation (perhaps immediately),
and
iii) clarifies what it means to deprecate a protocol whilst still 
allowing it as a "last resort" (or indeed consider changing it to 
straight deprecation)

Thank you for your attention and patience.

Ray H
[lurk]

---

From: Ray Hunter <[email-masked]>
Date: Thu, 21 Apr 2011 12:16:33 +0200

[delurk]
One thing that may be obvious to everyone on this list, but that is 
certainly worth pointing out for mere mortals like myself who took 
several days to work out the preference order of the rules governing 
selection of an IPv6 transition mechanism for a windows 7 box that had a 
public IPv4 address and was connected to a corporate network, but which 
also took part in Active Directory, but also had an IPv4 firewall 
between itself and the public Internet, and which was communicating with 
a Windows Server 2003 box that was going to be upgraded to Windows 2008, 
and where there was network intrusion detection in the path, and MPLS 
WRED QoS .......

http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 suggests 
(with some valid argument) that Teredo is worse than 6to4, because it 
uses tunnels (over UDP).

2.1.2. Teredo in the policy table

    Teredo's priority should be less than or equal to 6to4, considering
    its characteristic of being a transitional tunnel mechanism.  Windows
    already implements this.

"bad," "worse," "worst." There's only one worst.

So 6to4 and Teredo can't both be equally so bad that they're both "last 
resort."

And at the risk of repeating myself, not having any timetable for 
transition of the transition mechanism, or defining an extended period 
for the transition of a transition mechanism, is unlikely to make the 
average network administrators' life any easier.

Once again, thank you for your attention and patience.

Ray H
[lurk]