fred | 20 Dec 07:38 2014
Picon

Adoption call for draft-boucadair-6man-prefix-routing-reco

Are we agreed that draft-boucadair-6man-prefix-routing-reco should
be adopted as a working group document in v6ops, and renamed
draft-ietf-v6ops-cidr-prefix?

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

fred | 19 Dec 13:47 2014
Picon

new draft: draft-ietf-v6ops-siit-dc

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

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

Alexandru Petrescu | 19 Dec 12:18 2014
Picon

6man offspring - draft on prefix length recommendation for forwarding

Hello,

draft-boucadair-6man-prefix-routing-reco-03 is a new draft telling that 
forwarding processes should work with _arbitrary_ prefix lengths, and 
not be bound by particular limits, as an autoconfig process like 
SLAAC/Ethernet is bound by a prefix len max 64.

The draft was presented in 6MAN WG at the last IETF meeting in 
Honolulu[*].  The recommendation was to bring it to v6ops WG.

A glimpse to some topics discussed:
- worth or not having an RFC, since Internet acted this way since ever.
- cheaper searches below 64 and trends.
- Interface ID length vs. forwarding recommendation.

What do you think?

Alex
[*] the slides are at
http://www.ietf.org/proceedings/91/slides/slides-91-6man-6.pdf
Minutes are at:
http://www.ietf.org/proceedings/91/minutes/minutes-91-6man
(search for 'prefix')

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

(Continue reading)

internet | 18 Dec 16:55 2014
Picon

I-D Action: draft-ietf-v6ops-siit-dc-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Centre Environments
        Author          : Tore Anderson
	Filename        : draft-ietf-v6ops-siit-dc-00.txt
	Pages           : 31
	Date            : 2014-12-18

Abstract:
   This document describes SIIT-DC, an extension to the Stateless IP/
   ICMP Translation (SIIT) algorithm, that makes it ideally suited for
   use in IPv6 data centre environments.  SIIT-DC simultaneously
   facilitates IPv6 deployment and IPv4 address conservation.  The
   overall SIIT-DC architecture is described, as well as guidelines for
   operators.  Finally, the normative implementation requirements are
   described, as a list of additions and changes to SIIT.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-siit-dc/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-siit-dc-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
(Continue reading)

Michel Gosse | 17 Dec 11:48 2014
Picon

V6 World Congress Paris March 2015

The 2015 edition of V6 World will focus on IPv6 centric, country deployment status and measurement.

The agenda will also place particular emphasis on open source issues. Other sessions will cover in detail SDN, NFV and IoT challenges. 

 

More info: http://www.uppersideconferences.com/ipv6/v6_world_2015_agenda_conference_day_1.html

 

 

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tim Chown | 16 Dec 10:56 2014
Picon

Re: IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41)

On 15 Dec 2014, at 19:38, Templin, Fred L <Fred.L.Templin <at> boeing.com> wrote:
> 
> Hi Gert,
> 
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces <at> ietf.org] On Behalf Of Gert Doering
>> Sent: Monday, December 15, 2014 10:01 AM
>> To: Tariq Saraj
>> Cc: v6ops <at> ietf.org
>> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41
>> 
>> Hi,
>> 
>> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote:
>>> There are some issues with 6rd as well, IPv6 with all its powerful features
>>> is still under critical objections in academia just because of the urgency
>>> shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly
>>> mentioned that it cannot support multicast at layer-3, on the other end 6rd
>>> claimed that multicast can be provided, my question is that while
>>> standardizing 6rd which at that time was just supporting unicast traffic
>>> traversing across IPv4 network and its still not matured enough to provide
>>> multicast support yet in its functionality other than using some proxy
>>> support for multicast traffic. why It was standardized ?
>> 
>> There is no wide-area multicast anyway.
> 
> I don't know about that, but it does not hurt to be prepared to accommodate such.

Well, there is Embedded-RP, which is used inter-site. I believe it’s supported around much of the
academic/NREN networks. 

Or of course SSM.

But yes, the usage levels are ‘light’.

All our multicast streams used Embedded-RP, even though most are intra-site.

>> So why bother if a closed user
>> group decides to deploy a stopgap technology to enable IPv6 access.
> 
> Link- and site-scoped multicast might still be very beneficial, e.g., an operator
> sending a bulletin to all customers, etc. So, the ability to support IPv6 multicast
> within the operator network may be useful.
> 
>> And, when speaking about academia: do they have a "how to not write e-mail"
>> class there?  Like, "take a full digest with lots of unrelated mail in it,
>> and write a top posting on top of it"?
> 
> Please be gentle in providing guidance.

Well yes, top/tail is a personal preference. But let’s discuss multicast...

Tim
_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
Templin, Fred L | 15 Dec 20:38 2014
Picon

IPv6 multicast and tunnels (RE: v6ops Digest, Vol 52, Issue 41)

Hi Gert,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@...] On Behalf Of Gert Doering
> Sent: Monday, December 15, 2014 10:01 AM
> To: Tariq Saraj
> Cc: v6ops@...
> Subject: Re: [v6ops] v6ops Digest, Vol 52, Issue 41
> 
> Hi,
> 
> On Sun, Dec 14, 2014 at 12:18:00AM +0500, Tariq Saraj wrote:
> > There are some issues with 6rd as well, IPv6 with all its powerful features
> > is still under critical objections in academia just because of the urgency
> > shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly
> > mentioned that it cannot support multicast at layer-3, on the other end 6rd
> > claimed that multicast can be provided, my question is that while
> > standardizing 6rd which at that time was just supporting unicast traffic
> > traversing across IPv4 network and its still not matured enough to provide
> > multicast support yet in its functionality other than using some proxy
> > support for multicast traffic. why It was standardized ?
> 
> There is no wide-area multicast anyway.

I don't know about that, but it does not hurt to be prepared to accommodate such.

> So why bother if a closed user
> group decides to deploy a stopgap technology to enable IPv6 access.

Link- and site-scoped multicast might still be very beneficial, e.g., an operator
sending a bulletin to all customers, etc. So, the ability to support IPv6 multicast
within the operator network may be useful.

> And, when speaking about academia: do they have a "how to not write e-mail"
> class there?  Like, "take a full digest with lots of unrelated mail in it,
> and write a top posting on top of it"?

Please be gentle in providing guidance.

Thanks - Fred
fred.l.templin@...

> Gert Doering
>         -- NetMaster
> --
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
> 
> _______________________________________________
> v6ops mailing list
> v6ops@...
> https://www.ietf.org/mailman/listinfo/v6ops

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

Tariq Saraj | 13 Dec 20:18 2014
Picon

Re: v6ops Digest, Vol 52, Issue 41

There are some issues with 6rd as well, IPv6 with all its powerful features is still under critical objections in academia just because of the urgency shown by IETF in standardizing protocols like 6to4 and 6rd. 6to4 clearly mentioned that it cannot support multicast at layer-3, on the other end 6rd claimed that multicast can be provided, my question is that while standardizing 6rd which at that time was just supporting unicast traffic traversing across IPv4 network and its still not matured enough to provide multicast support yet in its functionality other than using some proxy support for multicast traffic. why It was standardized ? a common university level student is considering IPv6 nothing more than just a large address space. The support for multicast traffic is increasing every day at application level. My request at this forum is to consider 6rd along with the 6to4 so that in future both of these protocols not to become a part of any network device. I personally feels that instead of supporting to promote the IPv6 both of these protocols are becoming obstacles in this regards. I prefer using GRE over these automatic tunneling mechanisms at least GRE supports multicast on network layer and let the application program to design his/her application in more different ways.    

On Fri, Dec 12, 2014 at 1:00 AM, <v6ops-request-EgrivxUAwEY@public.gmane.org> wrote:
Send v6ops mailing list submissions to
        v6ops-CPo7pftKPww@public.gmane.orgg

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/v6ops
or, via email, send a message with subject or body 'help' to
        v6ops-request-EgrivxUAwEY@public.gmane.org

You can reach the person managing the list at
        v6ops-owner-EgrivxUAwEY@public.gmane.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of v6ops digest..."

Today's Topics:

   1. Re: Working Group Administrivia (Sheng Jiang)
   2. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
      (Keith Moore)
   3. Re: PMTUD forever, was: MTUs on the general Internet
      (Templin, Fred L)
   4. Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
      (Brian E Carpenter)


---------- Forwarded message ----------
From: Sheng Jiang <jiangsheng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: "t.petch" <ietfc-6b45v/Ft3lbby3iVrkZq2A@public.gmane.org>, "Fred Baker (fred)" <fred-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>, "v6ops-EgrivxUAwEY@public.gmane.org" <v6ops-EgrivxUAwEY@public.gmane.org>
Cc: 
Date: Thu, 11 Dec 2014 02:24:24 +0000
Subject: Re: [v6ops] Working Group Administrivia
Hi, Tom,

Thanks for your offer.

Review and comments would be very helpful for us to improve. Following the latest discussion, there are two actions we are planning: A) focus on the implementation divergence rather than a protocol definition problem statement. The most of contents are already in the current document. It just needs a little bit reorganizing and rewording. B) some addition investigation or experiments, e.g. both DHCPv6 and ND have DNS configuration.

If you are interested to contribute, you are certainly welcome.

Best regards,

Sheng

>-----Original Message-----
>From: t.petch [mailto:ietfc <at> btconnect.com]
>Sent: Thursday, December 11, 2014 1:39 AM
>To: Sheng Jiang; Fred Baker (fred); v6ops-EgrivxUAwEY@public.gmane.org
>Subject: Re: [v6ops] Working Group Administrivia
>
>Sheng
>
>If I read the e-mail addresses aright, you are the editor of
>draft-ietf-v6ops-dhcpv6-slaac-problem
>What do you want (that I might be able to do) bofore this is ready for
>WG Last Call?
>
>Tom Petch
>
>
>----- Original Message -----
>From: "Sheng Jiang" <jiangsheng-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>To: "t.petch" <ietfc <at> btconnect.com>; "Fred Baker (fred)"
><fred-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>; <v6ops-EgrivxUAwEY@public.gmane.org>
>Sent: Monday, December 08, 2014 2:18 AM
>Subject: RE: [v6ops] Working Group Administrivia
>
>
>> >As Brian says in his note,
>> >
>> >2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
>> >
>> >addresses a known problem and I think it would be remiss of the IETF
>not
>> >to have this documented
>>
>> Fully agreed. My read from the latest meeting response is the problem
>should be document and know by operators and implementors. The
>controversial part is not this draft, but the follow up of this draft:
>>
>> 1) The solution (protocol level) is not belong to v6ops WG.
>>
>> 2) The real debate is Whether v6ops should produce an operational
>guidelines for operators to avoid this issue. Personally, I think it is
>helpful and belong to this WG, but it seems the WG does not reach
>consensus on this.
>>
>> Best regards,
>>
>> Sheng
>>
>> >Tom Petch
>> >
>> >
>> >----- Original Message -----
>> >From: "Fred Baker (fred)" <fred-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
>> >To: <v6ops-EgrivxUAwEY@public.gmane.org>
>> >Sent: Friday, December 05, 2014 6:17 PM
>> >Subject: [v6ops] Working Group Administrivia
>> >
>> >
>> >Joel, Lee, and I spoke this morning about the status of the working
>> >group and various drafts in it. I’d like to gauge working group
>> >consensus on the status of a number of working group drafts that have
>> >either expired or otherwise should no longer be considered working
>group
>> >drafts. Your opinions, pro or con (such as “I’m fine with all that
>but
>> >think we should still be considering draft-whatever”), please:
>> >
>> >We think that the following can be safely set aside, by having the
>> >secretariat record (and show in the data tracker) that they are no
>> >longer working group drafts. They have expired, and are not currently
>> >being pursued:
>> >
>> >2003-01-13                     draft-ietf-v6ops-ipv4survey
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey/
>> >2003-02-14                 draft-ietf-v6ops-ipv4survey-gen
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv4survey-gen/
>> >2004-07-20                  draft-ietf-v6ops-v6onbydefault
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6onbydefault/
>> >2007-02-27             draft-ietf-v6ops-routing-guidelines
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-routing-guidelines/
>> >2007-03-28              draft-ietf-v6ops-campus-transition
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-campus-transition/
>> >2008-05-13         draft-ietf-v6ops-nat64-pb-statement-req
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-pb-statement-req
>/
>> >2011-07-26             draft-ietf-v6ops-v4v6tran-framework
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6tran-framework/
>> >2013-08-14                draft-ietf-v6ops-monitor-ds-ipv6
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-monitor-ds-ipv6/
>> >
>> >We think that draft-ietf-v6ops-balanced-ipv6-security, in its current
>> >state, is a deployment report, primarily from Swisscom. While the
>> >working group expressed interest in guidance on firewall
>configuration,
>> >this isn’t it. We think it should no longer be a working group draft,
>> >and invite the authors to submit it to the independent stream as a
>> >deployment report (<rfc-ise-i4YTrOVFbXmRpAAqCnN02g@public.gmane.org).
>> >
>> >2013-12-06         draft-ietf-v6ops-balanced-ipv6-security
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security
>/
>> >
>> >Although the working group expressed interest in the following and
>the
>> >authors have been working hard on them, we think the working group is
>no
>> >longer interested in these, and so they should be returned to the
>> >authors and not recorded or treated as working group drafts.
>> >
>> >2014-09-18                 draft-ietf-v6ops-design-choices
>> >http://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/
>> >2014-10-27           draft-ietf-v6ops-dhcpv6-slaac-problem
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/
>> >2014-10-27      draft-ietf-v6ops-ula-usage-recommendations
>>
>>http://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommendati
>o
>> >ns/
>> >
>> >Speaking for myself, if I have any question of the above, it is on
>only
>> >one of these.
>> >
>> >If any draft has its "WG Draft" status revoked, it will still be
>> >available from the IETF website as far as I know, but subsequent
>> >revisions should be named as individual submissions to a working
>group,
>> >draft-<author>-<wg>-<subject> or individual submissions to the IETF,
>> >draft-<author>-<subject>. It would be good if the authors would send
>a
>> >note to internet-drafts-EgrivxUAwEY@public.gmane.org indicating that the old draft name
>were
>> >replaced by the new draft name, so that the revision history is
>tracked
>> >appropriately.
>> >
>> >Opinions?
>> >
>> >
>> >
>> >
>>
>>-----------------------------------------------------------------------
>-
>> >--------
>> >
>> >
>> >>
>> >>
>> >
>> >
>>
>>-----------------------------------------------------------------------
>-
>> >--------
>> >
>> >
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> v6ops-EgrivxUAwEY@public.gmane.org
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >
>> >_______________________________________________
>> >v6ops mailing list
>> >v6ops-EgrivxUAwEY@public.gmane.org
>> >https://www.ietf.org/mailman/listinfo/v6ops
>>



---------- Forwarded message ----------
From: Keith Moore <moore-zZ82ZiX1S8nyYVEdmRSQwFaTQe2KTcn/@public.gmane.org>
To: v6ops-EgrivxUAwEY@public.gmane.org
Cc: 
Date: Thu, 11 Dec 2014 10:42:54 -0500
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
Mumble.  I support the deprecation of 192.88.99.1 as a means to find 6to4 relays.   But this document still contains so many inaccurate and misleading statements beyond that, including perhaps some statements that were not present in earlier versions (though I haven't taken the time to check yet), that I don't believe it should be published in its current form. Again, this is a document quality issue, not an issue with the basic underlying recommendation.

Most of the problems with this document are things that I have already mentioned in connection with earlier versions of this document.

Keith




---------- Forwarded message ----------
From: "Templin, Fred L" <Fred.L.Templin-X8CqP27nNzzQT0dZR+AlfA@public.gmane.org>
To: Jeroen Massar <jeroen-1ptKdY9IqObtRgLqZ5aouw@public.gmane.org>, "sthaug-5U4UkxQHZ+huMpJDpNschA@public.gmane.org" <sthaug-5U4UkxQHZ+huMpJDpNschA@public.gmane.org>
Cc: "v6ops-EgrivxUAwEY@public.gmane.org" <v6ops <at> ietf.org>
Date: Thu, 11 Dec 2014 16:10:44 +0000
Subject: Re: [v6ops] PMTUD forever, was: MTUs on the general Internet
> More on what I said the other day, there are two magic numbers that tunnels
> need to concern themselves with: 1280 and 1500. Accommodating all packets
> within that size range while placing no explicit upper bound for accommodating
> larger packets is what is being proposed. In other words, no MTU clamping.

Have we reached conclusion on this, and can it now be considered "case closed"?

Remember - "take care of the smalls, and let the bigs take care of themselves":

https://datatracker.ietf.org/doc/draft-templin-aerolink/
https://datatracker.ietf.org/doc/draft-templin-aeromin/

Thanks - Fred
fred.l.templin-X8CqP27nNzzQT0dZR+AlfA@public.gmane.org




---------- Forwarded message ----------
From: Brian E Carpenter <brian.e.carpenter <at> gmail.com>
To: Keith Moore <moore-zZ82ZiX1S8nyYVEdmRSQwFaTQe2KTcn/@public.gmane.org>
Cc: v6ops-EgrivxUAwEY@public.gmane.org
Date: Fri, 12 Dec 2014 08:23:12 +1300
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
Keith, please, you need to be specific about what you think is
inaccurate or misleading, line by line, in this version. There's
nothing we can do with a general criticism like that.

We have made numerous changes, some of them in response to your
comments, but of course in some cases your comments were at
variance with other peoples' comments. Of course, there were a
lot of messages, many of them completely orthogonal to the text
of the draft, so we may well have missed some of the relevant ones.

Regards
   Brian

On 12/12/2014 04:42, Keith Moore wrote:
> Mumble.  I support the deprecation of 192.88.99.1 as a means to find
> 6to4 relays.   But this document still contains so many inaccurate and
> misleading statements beyond that, including perhaps some statements
> that were not present in earlier versions (though I haven't taken the
> time to check yet), that I don't believe it should be published in its
> current form. Again, this is a document quality issue, not an issue with
> the basic underlying recommendation.
>
> Most of the problems with this document are things that I have already
> mentioned in connection with earlier versions of this document.
>
> Keith
>
> _______________________________________________
> v6ops mailing list
> v6ops-EgrivxUAwEY@public.gmane.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



_______________________________________________
v6ops mailing list
v6ops-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/v6ops



--
Regards
Tariq Saraj
Center for Research in Networks and Telecom (CoReNeT)
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tore Anderson | 13 Dec 17:10 2014
Picon

New Version Notification for draft-anderson-v6ops-siit-eam-02.txt

Hello,

I've uploaded a new version of draft-anderson-v6ops-siit-eam. The
significant changes are:

- Describe the address translation algorithm as detailed step-by-step
  procedure, one section for IPv4->IPv6 and another for IPv6->IPv4. I
  hope this addresses Cameron's misgivings about the language in -01.
- Allow EAM entries to have longer IPv6 suffixes than IPv4. This is
  required to support IVI address mappings. When translating from IPv4
  to IPv6, the missing suffix bits are zero padded; when translating
  from IPv6 to IPv4, the superfluous suffix bits are discarded.
- Include a section in the appendix that describes the IVI use case.
- Include a section in the appendix that shows the outcome of the
  algorithm for various example addresses using a number of example
  EAMs.

Tore

Forwarded message:

A new version of I-D, draft-anderson-v6ops-siit-eam-02.txt
has been successfully submitted by Tore Anderson and posted to the
IETF repository.

Name:		draft-anderson-v6ops-siit-eam
Revision:	02
Title:		Explicit Address Mappings for Stateless IP/ICMP Translation
Document date:	2014-12-13
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-anderson-v6ops-siit-eam-02.txt
Status:         https://datatracker.ietf.org/doc/draft-anderson-v6ops-siit-eam/
Htmlized:       http://tools.ietf.org/html/draft-anderson-v6ops-siit-eam-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-anderson-v6ops-siit-eam-02

Abstract:
   This document extends the Stateless IP/ICMP Translation Algorithm
   (SIIT) with an Explicit Address Mapping (EAM) algorithm, and formally
   updates RFC 6145.  The EAM algorithm facilitates stateless IP/ICMP
   translation between arbitrary (non-IPv4-translatable) IPv6 endpoints
   and IPv4.

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

Fred Baker (fred | 13 Dec 07:56 2014
Picon

Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt



Begin forwarded message:

Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
Date: December 12, 2014 at 4:56:26 PM PST

Section 1:
There would appear to be little evidence of substantial active use of the original form of 6to4 described in [RFC3056].
This statement is unsupported, and I believe, superfluous.    Such a statement might be supportable via traffic measurements, depending on how the measurements were done.   But traffic measurements are often misinterpreted, and without a reference describing actual methods and results there's no way for the reader to assess the validity of the statement.   Whether it's a defensible statement also depends on what "substantial" means.    Anyway, the document would be stronger without it, as the document shouldn't really be about RFC 3056.

Recommendation: delete this sentence.

[RFC6343] analyses the known operational issues in detail and describes a set of suggestions to improve 6to4 reliability, given the widespread presence of hosts and customer premises equipment that support it. However, experience shows that operational failures have continued despite this advice being available. Fortunately the advice to disable 6to4 by default has been widely adopted in recent operating systems, and the failure modes have been largely hidden from users by many browsers adopting the "Happy Eyeballs" approach [RFC6555]. Nevertheless, a substantial amount of 6to4 traffic is still observed and the operational problems caused by 6to4 still occur. Although facts are hard to obtain, the remaining successful users of anycast 6to4 are likely to be on hosts using the obsolete policy table [RFC3484] (which prefers 6to4 above IPv4), without Happy Eyeballs, with a route to an operational anycast relay, and accessing sites that have a route to an operational return relay. Taken together these statements seem confusing at best.   Here's my attempt to sort things out:  

  • Measures that have been taken in the past (recommending disabling 6to4 by default, use of happy eyeballs) have had some useful effect. 
  • However some hosts are still observed (again, without any reference to the observations) to use 6to4 and have operational problems doing so.  
  • Presumably the hosts that are still having operational problems are those that have, for whatever reason, failed to implement those measures (perhaps because they are running obsolete code, perhaps because they are behind routers that implement 6to4).   (Perhaps it is believed that publishing additional RFCs discouraging 6to4 use will help reduce those problems, as if somehow users will upgrade their systems and/or routers because we publish more RFCs.)

Much of the latter paragraph seems completely unsupportable.   The RFC3484 prefix selection table doesn't affect address selection for applications requiring or deliberately preferring IPv6 (say to circumvent NAT) and having only a single IPv6 address.  (Perhaps the authors are under the impression that the only hosts anyone wishes to communicate with using anycast 6to4 are those which also have IPv4 addresses, or the only apps using IPv6 are those which could work equally well through IPv4 NAT?)   Happy Eyeballs isn't generally applicable to all applications using IPv6, and even when it's useful only helps if there are multiple source/destination address pairs from which to choose.   Again, it's not correct to assume that either end of traffic using 6to4 has an IPv4 address that would work better for that application.  Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage.

Of course successful use of 6to4 does require routes to working relays in both directions.

Recommendation: reword the former paragraph and (especially) delete the latter one.

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969] explicitly builds on the 6to4 mechanism, and could be viewed as a superset of 6to4, using a service provider prefix instead of 2002::/16. However, the deployment model is based on service povider support, such that 6rd can avoid the problems described here. In this sense, 6rd can be viewed as superseding 6to4 as described in section 4.2.4 of [RFC2026].   While 6rd is indeed useful, and it seems like a good solution for access providers wishing to provide their customers with an interim IPv6 solution until they deploy native IPv6, it is  misleading to call it a "superset" of 6to4 or to claim that it supersedes it.  6rd would be better described as a subset, since it's potentially applicable in fewer situations than 6to4 is.   Or perhaps it would be better to say that 6rd and 6to4 have different use cases.   In particular, 6rd doesn't provide any help to a user needing to reach IPv6 hosts if the ISP to which he's currently connected doesn't support it.

Recommendation: delete the paragraph.  6rd is irrelevant to this document.

Given that native IPv6 support and various reliable transition mechanisms are now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism. Whether native IPv4 support or reliable transition mechanisms are "becoming common" depends on your definition of "common", but we're still a long way from a point where such mechanisms are generally available and applicable to ordinary users.   The main reason that there's no evolutionary future for the 6to4 mechanism is exhaustion of IPv4 address space and widespread deployment of NAT including carrier-side NAT.    (The problems with use of anycast could be fixed if there were much to be gained by fixing them, but the inevitably-increasing use of carrier-side NAT means there's really no point in doing so.)   Also, the paragraph could be taken to mean that these "reliable transition mechanisms" are good substitutes for 6to4, when reality is that there is currently no good replacement for 6to4.

Recommendation: reword to say "Given that due to exhaustion of IPv4 address space carrier-side NAT is now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism"

Section 3:

With the increased deployment of IPv6, the mechanism has been shown to have a number of fundamental shortcomings.
Some of these shortcomings are not specifically shortcomings with 6to4, but rather shortcomings of original address selection rules (which incorrectly assumed that any v6 path would work at least as well as any v4 path), the Internet architecture itself (poor support for multihomed hosts which manifests in several ways and persists to this day)

o Use of relays. 6to4 depends on an unknown third party to operate the relays between the 6to4 cloud and the native IPv6 Internet. I think this is redundant with the 3rd bullet, and the 3rd bullet states it better.
 o The placement of the relay can lead to increased latency, and in the case the relay is overloaded, packet loss. While this statement is true on its face, it's sort of meaningless or misleading.    It begs the question "increased latency as compared to what?"   6to4 actually did a fairly good job of finding nearby relays in both directions if they were available - often providing lower latency better than configured tunnels except those provided by one's own ISP.  

The real problem was with the original address prefix selection algorithm and its implicit assumption that any IPv6 path would be better than any IPv4 path.    If ISPs around the world had deployed native IPv6 15 years ago but initially with suboptimal routing, the same problem of decreased latency would have appeared due to hosts' blind preference of v6 over v4.  

For that matter, the intended purpose of 6to4 (or for that matter IPv6) never was to facilitate communications between hosts or application peers that could just as well use IPv4.
 o There is generally no customer relationship between the end-user and the relay operator, or even a way for the end-user to know who the relay operator is, so no support is possible. Agreed.
o A 6to4 relay for the reverse path and an anycast 6to4 relay used for the forward path, are openly accessible, limited only by the scope of routing. 6to4 relays can be used to anonymize traffic and inject attacks into IPv6 that are very difficult to trace. Two things: The first statement is true but as far as I can tell only half of it is relevant - the "reverse" (6->4) path relay doesn't permit anonymizing traffic as far as I can tell.  The "forward" (4->6) path relay permits anonymizing traffic if the relay doesn't check that the IPv4 source address on the inbound packet is consistent with the IPv6 source address on the inbound packet.   Otherwise, the degree of anonymizing possible is about the same as with NAT44 - the rest of the network can't tell which host the traffic came from but it can tell which network it came from.

o 6to4 may silently discard traffic in the case where protocol (41) is blocked in intermediate firewalls. Even if a firewall sent an ICMP message unreachable back, an IPv4 ICMP message rarely contains enough of the original IPv6 packet so that it can be relayed back to the IPv6 sender. That makes this problem hard to detect and react upon by the sender of the packet. Well, of course it's not 6to4 discarding the traffic, it's the firewalls.   Place the blame where it belongs.   And these problems exist with protocol 41 tunnels in general, including 6rd tunnels, not just 6to4 tunnels.   (It seems especially odd for this document
to be recommending 6rd as a replacement of sorts for 6to4 while at the same time
citing 6to4 for shortcomings that are also present with 6rd.)

There are really two issues here:
- "accidental" blocking of 6to4 by firewalls (i.e. because of naivete or misconfiguration rather than because of explicit policy)
- hosts/apps not coping well with blocking of 6to4 by firewalls

Recommendation: separate into two bullets:

- 6to4 traffic was sometimes silently discarded by firewalls, either because they blocked
protocol 41 indiscriminately, or because they blocked incoming traffic flows that weren't initiated by outgoing traffic flows, and were not configured to recognize outgoing flows over protocol 41.   Sometimes this blocking was deliberate, sometimes accidental due to underspecified configuration.

- Whether or not by accident, when encapsulated traffic was blocked by a IPv4-only firewall, an ICMPv4 response from the firewall was unlikely to be useful to the sender's IPv6 stack, and an IPv4-only firewall generally wouldn't know how to send ICMPv6 responses encapsulated in IPv4, to the sending host.  



o As 6to4 tunnels across the Internet, the IPv4 addresses used must be globally reachable. RFC 3056 states that a private address [RFC1918] MUST NOT be used. 6to4 will not work in networks that employ other addresses with limited topological span. In particular it will predictably fail in the case of double network address translation (NAT444).
This bullet seems very muddy.

"As 6to4 tunnels across the Internet"  should say "the IPv4 Internet".   The Internet isn't just IPv4.

The second sentence seems out of place.   It's not immediately clear what RFC 3056's statement about RFC 1918 addresses has to do with the argument that's being made.

- The general issue is that 6to4 doesn't work to provide IPv6 access to hosts or routers lacking a globally-scoped and globally-reachable IPv4 address.   This in combination with widespread use of NAT made 6to4 much less useful than it would otherwise have been, and is perhaps the biggest single problem with 6to4.

- A related problem was that it wasn't clear from the 6to4 specifications that hosts and routers supporting 6to4 needed a reliable way to detect that they had globally-scoped and globally-reachable IPv4 addresses.  RFC 1918 addresses were excluded by RFC 3056, but other unsuitable IPv4 addresses were not as easily recognized.  

- Some 6to4 implementations were once known to enable 6to4 by default for any non-RFC1918 address, having the effect of enabling a IPv6 address and interface that would never work, and (in the absence of modern address selection rules or happy eyeballs) causing traffic to be blackholed.   However this problem has largely been fixed.

As far as I can tell, the problem with double NAT is just one example of the general problem.   Even a single layer of NAT breaks 6to4.

Recommendation: reword the above bullet into two separate bullets, along the lines above.



_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tim Chown | 9 Dec 22:51 2014
Picon

Re: Working Group Administrivia

On 9 Dec 2014, at 15:33, Fred Baker (fred) <fred@...> wrote:
> 
> Let me ask specifically about the “ULA” and “Design Choices” documents. They have not expired
and their authors are still working on them. Brian has commented; others have not. Do we want to keep
working on them?

Oh, and I’d also support Brian’s proposal to move the ULA ‘guidance' (rather than
‘recommendations’) to the design choices document, which is an appropriate place to discuss the
tradeoffs with their use in different contexts.

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

Gmane