fred | 23 Nov 20:00 2014
Picon

draft-ietf-v6ops-6to4-to-historic WGLC

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

fred | 22 Nov 13:47 2014
Picon

new draft: draft-anderson-v6ops-siit-eam

A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-siit-eam. Please
take a look at it and comment.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Tore Anderson | 21 Nov 14:12 2014
Picon

Fw: I-D Action: draft-anderson-v6ops-siit-eam-00.txt

Hello WG,

This draft is an attempt to work in Dave Thaler's comments directed at
SIIT-DC during the v6ops session, namely that «this isn't a new
protocol, just good use cases» (quote from the published minutes).

The missing piece from the existing set of protocols is the ability to
provide static IPv4,IPv6 mappings that override RFC6052. Currently, I
cannot go to a router vendor and ask for an "implementation of RFC X"
that can be used for SIIT-DC:

- RFC 6144 doesn't suffice, as it does not specify any protocols, and
  as such cannot be implemented per se.
- RFC 6145 doesn't suffice, as it mandates that a stateless translator
  must use the RFC6052 algorithm for all address translations (except
  ICMPv6->ICMPv4, through the update in RFC6791)
- RFC 6146 doesn't suffice, because it brings with it a lot of unwanted
  stateful stuff (Session Tables and Binding Information Bases, for
  example)

This document attempts to remedy this shortcoming by updating SIIT
(RFC6145) directly, adding the static mapping functionality. This way,
I can take the SIIT-DC documents off the standards track, and focus on
describing the particular data centre use case, without specifying any
new protocols.

The draft also attempts to clarify the rationale for the static
mappings, also requested by Dave Thaler, by including a "Problem
Statement" section. It also includes a section noting that the
translations are not checksum neutral, as pointed out by Andrew
(Continue reading)

Tim Chown | 21 Nov 13:31 2014
Picon

Re: On IPv6 address part naming

Hi,

On 21 Nov 2014, at 10:32, Alexandru Petrescu
<alexandru.petrescu@...> wrote:

> Le 20/11/2014 22:34, Brian E Carpenter a écrit :
>> On 21/11/2014 09:02, Joe Touch wrote:
>>> 
>>> On 11/20/2014 11:40 AM, Brian E Carpenter wrote:
>>>> This is a problem I've never had. However, the correct term, derived from
>>>> Latin in the same way as "octet", is "sexdectet"*.
>>> 
>>> Latin for 8 is octo, for 16 is sedecim.
>>> 
>>> Given octo -> octet, sedecim -> "sedecet" or "sedecimet"
>>> (see https://www.mail-archive.com/tech-MDFyBgYyG8FQTh5j9rE+rA <at> public.gmane.org/msg00058.html)
>> 
>> Well, I went by an authority known as Google. I suspect there are
>> differences between Latin as spoken in Rome 2k years ago, and Latin
>> as written in the Middle Ages. I can no longer remember the Latin I
>> was forced to learn at grammar school.
> 
> And Latin lives on, e.g. B. XVI - "Decimus Sextus" (ten and six), hint by which we'd say "decimus-sextet", "decisextet”.
> https://www.ietf.org/mailman/listinfo/v6ops

This will run and run over the weekend!

There’s many ways to say it. What matters is the meaning is clear when it’s explained.

I tend to say ‘eight sets of four hexadecimal digits’ or sometimes just ‘eight hex quads’.  The
(Continue reading)

Richard Hartmann | 20 Nov 19:03 2014
Picon

On IPv6 address part naming

Dear all,

as you may remember, I tried to push a draft on IPv6 address naming[1]
back in 2010 on both v6ops [2] and 6man [3].

As I finally have enough spare cycles again I want to try and push
this as a WG item within v6ops one last time.

If this proves to be too controversial I will go the route of
Informational Independent Submission, but I would really prefer to do
this within this WG.

Thanks,
Richard

[1] https://github.com/RichiH/draft-hartmann-ipv6-addresspartnaming
[2] http://www.ietf.org/mail-archive/web/v6ops/current/msg05899.html
[3] http://www.ietf.org/mail-archive/web/ipv6/current/msg13805.html

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Tim Chown | 19 Nov 08:35 2014
Picon

Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt

On 18 Nov 2014, at 21:30, sthaug@... wrote:

>>> Despite being a paid-up member of the burn-6to4-with-fire camp, I really
>>> don't think that the IETF should recommend that operators actively block
>>> their end-users from being able to do something, even if we all think it's
>>> a rotten poor idea.  The protocol is dying quite nicely by itself without
>>> operator intervention.
>> 
>> The goal is to not break active and successful users of 6to4.  However, 
>> we don't want to perpetuate zombiefied (half-broken) 6to4 relays either. 
>>  If it is Ok for relay server operators to turn-off relays, at some 
>> point it needs to be Ok for network operators to not carry the route as 
>> well.
> 
> We turned off our 6to4 relay at the end of 2012. We certainly have
> no plans to turn it on again. 
> 
> However - I see no need to deliberately remove the 192.88.99.1 route.
> It will disappear when the last 6to4 relay is turned off.

I wonder what the first publicly announced IPv4 6to4 relay was. Perhaps SWITCH (via Simon Leinen) or FUNET
(Pekka Savola)?  I remember the days of SWITCH’s relay being a world 6to4 magnet.

Would be poetic to let them be the last to switch off too, if they’re still running :)

Tim
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
(Continue reading)

Tim Chown | 18 Nov 16:10 2014
Picon

Re: draft-ietf-v6ops-6to4-to-historic WGLC

Hi,

On 18 Nov 2014, at 13:28, Gert Doering <gert@...> wrote:

> Hi,
> 
> On Tue, Nov 18, 2014 at 08:20:18AM -0500, Keith Moore wrote:
>> On 11/18/2014 05:52 AM, Gert Doering wrote:
>>> On Tue, Nov 18, 2014 at 02:04:50AM -0500, Keith Moore wrote:
>>>> Also, 6to4 hasn't hurt more people than it helped.
>>> Now *that* is a very bold statement, which (for the anycast relay 6to4)
>>> really contradicts existing measurements.  But of course with an
>>> adequate definition of "hurt" and "help", anything can be true.
>> It doesn't contradict existing measurements, just how those measurements 
>> are interpreted.   If you interpret those measurements according to an 
>> assumption that the network is in all respects functioning correctly 
>> except for 6to4, you'll conclude that 6to4 is the problem.   But that's 
>> not a valid premise, as we know that the network is not functioning 
>> correctly in a great many respects.
> 
> The measurements quite clearly demonstrate that anycasted 6to4 works
> *less* well than native IPv4.  This is not assuming IPv4 works 100%.
> 
> [..]
>>> But I'm sure you know that quite well, and the draft authors already
>>> agreed to not deprecate your RFC, so I wonder what you are argueing for?
>> 
>> Truth.   Or is truth out-of-scope?
>> 
>> More precisely:   I accept that as a practical matter, 6to4 is doomed 
(Continue reading)

Keith Moore | 17 Nov 23:18 2014

Re: draft-ietf-v6ops-6to4-to-historic WGLC

On 11/17/2014 04:32 PM, Ole Troan wrote:
> Mark,
>
>> This draft does *harm* to the set of people for whom 6to4 anycast
>> works.  It actively sabotages their working connections by filtering
>> the routing information required to reach the relay.  It recommends
>> that 6to4 support be removed from / not added to products making
>> upgrading existing equipement (harware and software wise) dangerous
>> for those that have working 6to4 connections.
> who are those people?
> since 6to4 depends on 2 3rd party operated relays to function. which outbound relay you use depends on IPv4
routing, which return relay you use depend on IPv6 routing from the perspective of the destination. which
means which return relay is used depends on which destination you are communicating with.

Isn't the latter true for IP traffic in general?  The fact that the last 
link is a tunnel over IPv4 doesn't change that.

As far as I can tell path asymmetry is the usual case, not the exception.

Even for the IPv4->IPv6 part of the path, the fact that it uses IPv4 
routing doesn't seem like what's broken or what causes problems.  IPv4 
routing works fine most of the time.   However, every RFC 3068 v4->v6 
router effectively having the same IPv4 address - that does cause 
problems for diagnosis, especially from the user end.

> it is therefore hard to see  a scenario where 6to4 would work reliably.
It's also hard to see how the Internet would work reliably.   :)

Seriously, if we're going to discourage use of 6to4, or even just 
discourage use of anycast relays, let's try to be precise about the 
(Continue reading)

Mark Andrews | 17 Nov 23:02 2014

Re: draft-ietf-v6ops-6to4-to-historic WGLC


In message <506DB2D3-F2E2-4437-B2CB-2DB9000F548A@...>,
Ole Troan writes:
> Mark,
>
> > This draft does *harm* to the set of people for whom 6to4 anycast
> > works.  It actively sabotages their working connections by filtering
> > the routing information required to reach the relay.  It recommends
> > that 6to4 support be removed from / not added to products making
> > upgrading existing equipement (harware and software wise) dangerous
> > for those that have working 6to4 connections.
>
> who are those people?
> since 6to4 depends on 2 3rd party operated relays to function. which
> outbound relay you use depends on IPv4 routing, which return relay you
> use depend on IPv6 routing from the perspective of the destination. which
> means which return relay is used depends on which destination you are
> communicating with.

I know how 6to4 works.  I also know how it can be broken.  I know
its disavantages.  Despite all that it works for some people and
this draft is actively trying to harm those people.

> it is therefore hard to see  a scenario where 6to4 would work reliably.
> please refer back to the measurements that Geoff has done. or do you have
> different measurements?

Does Geoffs figure say 0% work?  Just because it does not work for
some (or even many) does not mean that it does not work for all.
Last time I checked 6to4 worked fine for me.
(Continue reading)

fred | 16 Nov 20:00 2014
Picon

draft-ietf-v6ops-6to4-to-historic WGLC

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Keith Moore | 16 Nov 04:45 2014

comments on draft-ietf-v6ops-6to4-to-historic-08

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.)

(Continue reading)


Gmane