Fred Baker (fred | 28 Jan 17:57 2015
Picon

draft-ietf-v6ops-mobile-device-profile last call

draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of change in the IESG. The ADs would
like to see the working group read it again and comment - working group last call - before they proceed. To
summarize, it provides requirements for handsets that would work in a specific business model. As such,
it builds on RFC 6434 and 7066, strengthening some of those requirements, and going on to add requirements
related to 464xlat and other technologies.

Please read it now, and comment. This WGLC will run until 15 February.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 28 Jan 13:47 2015
Picon

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

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

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

Fred Baker (fred | 26 Jan 06:03 2015
Picon

draft-ietf-v6ops-siit-dc-2xlat

We agreed to take draft-anderson-v6ops-siit-dc as a working group draft; it is now posted as
draft-ietf-v6ops-siit-dc. I’m not clear on draft-anderson-v6ops-siit-dc-2xlat; Tore has done the
work to post it as draft-ietf-v6ops-siit-dc-2xlat, but I don’t know the collected opinion. Do we want
it (and do we want draft-anderson-v6ops-siit-dc-eam) as working group drafts?
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 21 Jan 13:47 2015
Picon

new draft: draft-ietf-v6ops-cidr-prefix

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

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

fred | 18 Jan 20:00 2015
Picon

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

This is to initiate a one 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

Tim Chown | 13 Jan 10:39 2015
Picon

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

Hi,

On 13 Jan 2015, at 03:27, Lorenzo Colitti <lorenzo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

I do not object to saying that implementations SHOULD support the rules in RFC6724.

Yes, definitely.

HE was a necessary hack at the time, and it made perfect sense if Google were doing v6 for World IPv6 Day in 2011 that they could implement something HE-like and say their browser would be resilient to the 20+ second delays we saw otherwise back at that time. I think I even stayed on Chrome after that day, so the ploy worked ;)

I think an interesting approach is as described in draft-ietf-mif-mpvd-arch-08, which blends many considerations including multiple interfaces, providers and protocols. But for this draft, RFC6724 should be the go to reference.

Tim

On Tue, Jan 13, 2015 at 12:17 PM, David Farmer <farmer-OJFnDUYgAso@public.gmane.org> wrote:


On Jan 12, 2015, at 20:54, Lorenzo Colitti <lorenzo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

On Sat, Jan 10, 2015 at 6:44 AM, David Farmer <farmer-OJFnDUYgAso@public.gmane.org> wrote:
   All hosts using 6to4 SHOULD support the IPv6 address selection
   policy described in [RFC6724] or be manually configured with an
   address selection policy preferring IPv4 over a 6to4 source
   address.  Further, 6to4 hosts SHOULD support "Happy Eyeballs"
   [RFC6555] or use a browser supporting "Happy Eyeballs".  Any hosts
   not meeting these requirements SHOULD NOT use, or continue to use,
   the deprecated anycast 6to4 mechanism.

I disagree that implementations should support happy eyeballs. Happy eyeballs is a hack that came into being to avoid broken IPv6 implementations. (I know, because I was there; and before anyone argues with me - were you?) It adds application complexity and makes debugging harder in order to overcome problems that would not exist if the network were properly configured, and it encourages misconfiguration to persist because it masks the effects of misconfiguration. We should not perpetuate it; we should instead be moving beyond it.

Just because Happy Eyeballs is a standards track RFC doesn't mean that hosts have to implement it.

Ok, I'm fine without Happy Eyeballs, it is most defiantly a hack, like I said it seemed to jump out of the Introduction as a conclusion.  What about the other half?  If you going to continue to use anycast 6to4 should there be a requirement or recommendation to support RFC6724 or be manually configured with an address selection policy preferring IPv4 over a 6to4 source address?

-- 
===============================================
David Farmer                          Email: farmer-OJFnDUYgAso@public.gmane.org
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

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

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Alberto Leiva | 12 Jan 22:57 2015
Picon

About RFC 6791

Hello

I'm trying to make sense out of RFCs 6791 and 5837 and I have three questions.

RFC 6791 says

>   the translator SHOULD implement the ICMP
>   extension defined by [RFC5837].  The ICMP message SHOULD include the
>   Interface IP Address Sub-Object and specify the source IPv6 addresses
>   of the original ICMPv6.

(1st question) Does this mean the extension should be replaced, or
should it be appended?
As in, if the packet already has an Interface Information Object
(IIO), what should the translator do with it?

Replacing sounds aggressive.
Appending sounds dangerous because it risks interfering with this from RFC 5837:

>   A single ICMP message MUST NOT contain two
>   Interface Information Objects that specify the same role.

(2nd question) What is the interface role the translator should write
in the C-Type of the IIO? (rfc5837, page 8)
RFC 6791 seems silent on this. I'm kind of casually assuming value 2
sounds like the least incorrect one, and at the same time it feels
like I'm completely missing the point of 2.
None of them seem overly concerned with remote interfaces (ie. the
translator is writing an IIO of an interface that belongs to someone
else).

(3rd question) "sub-IP component" doesn't seem to be defined anywhere.
What am I missing?

Thank you
Alberto

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

internet | 12 Jan 11:13 2015
Picon

I-D Action: draft-ietf-v6ops-mobile-device-profile-15.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           : An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices
        Authors         : David Binet
                          Mohamed Boucadair
                          Ales Vizdal
                          Gang Chen
                          Nick Heatley
                          Ross Chandler
	Filename        : draft-ietf-v6ops-mobile-device-profile-15.txt
	Pages           : 18
	Date            : 2015-01-12

Abstract:
   This document defines a profile that is a superset of that of the
   connection to IPv6 cellular networks defined in the IPv6 for Third
   Generation Partnership Project (3GPP) Cellular Hosts document.  This
   document identifies features to deliver IPv4 connectivity service
   over an IPv6-only transport as well as the required features to
   connect 3GPP mobile devices to an IPv6-only or dual-stack wireless
   network (including 3GPP cellular network and IEEE 802.11 network).

   Both hosts and devices with capability to share their WAN (Wide Area
   Network) connectivity are in scope.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-mobile-device-profile-15

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/

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

fred | 11 Jan 20:00 2015
Picon

draft-boucadair-6man-prefix-routing-reco 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

internet | 4 Jan 20:04 2015
Picon

I-D Action: draft-ietf-v6ops-6to4-to-historic-10.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           : Deprecating Anycast Prefix for 6to4 Relay Routers
        Authors         : Ole Troan
                          Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-to-historic-10.txt
	Pages           : 7
	Date            : 2015-01-04

Abstract:
   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that
   when used in its anycast mode, the mechanism is unsuitable for
   widespread deployment and use in the Internet.  This document
   therefore requests that RFC 3068, "An Anycast Prefix for 6to4 Relay
   Routers", be made obsolete and moved to historic status.  It also
   obsoletes RFC 6732 "6to4 Provider Managed Tunnels".  It recommends
   that future products should not support 6to4 anycast and that
   existing deployments should be reviewed.  This complements the
   guidelines in RFC 6343.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-10

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/

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

fred | 4 Jan 20:02 2015
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


Gmane