Lorenzo Colitti | 16 Apr 10:22 2014
Picon

Re: Please review the No IPv4 draft

Ok. So:
  1. As regards impact to the client - "don't waste your resources sending DHCPv4 requests, there's never going to be a DHCPv4 server here", then: what's the advantage to the client above doing exponential backoff with one packet every 2 minutes / half hour / 2 hours? True, clients don't do exponential backoff today, but they will have to be modified anyway for this option to work.
  2. As regards impact to the infrastructure: on wifi, infrastructure-to-client broadcasts are expensive, but client-to-infrastructure broadcasts are effectively unicast. So just configuring the AP to drop the packets will do what you want. As regards to low-power clients, see #1.
Don't get me wrong - I don't think this is harmful (modulo security considerations, of course). I just don't think it's a particularly good use of our time.

If we do do this, on the face of it it would seem that from the host's perspective it would be better to have this information in DHCPv4 than in DHCPv6.

Cheers,
Lorenzo


On Tue, Apr 15, 2014 at 1:57 PM, Owen DeLong <owen-HABLESmikyvQT0dZR+AlfA@public.gmane.org> wrote:

On Apr 14, 2014, at 9:20 PM, Lorenzo Colitti <lorenzo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

On Mon, Apr 14, 2014 at 11:50 PM, Simon Perreault <simon.perreault <at> viagenie.ca> wrote:
In a nutshell, it defines DHCPv6 and RA options indicating to the host
that IPv4 is not available. Reviews from operations-minded people in
V6OPS would be of tremendous help.

I don't see a strong use case for this. It seems to me that the two scenarios in the introduction can be solved by simply configuring the DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests.

Am I missing something?

I believe the purpose is to get the DHC4 client to stop asking (broadcast DHCP4 requests) on networks where repeated garbage packets are less than desirable (low power applications, wifi, etc.)

Owen


_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Simon Perreault | 14 Apr 16:50 2014
Picon

Please review the No IPv4 draft

Dearest V6OPS,

We are soliciting reviews for this SUNSET4 draft:

http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00

In a nutshell, it defines DHCPv6 and RA options indicating to the host
that IPv4 is not available. Reviews from operations-minded people in
V6OPS would be of tremendous help.

Thanks,
Simon
--

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

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

Fred Baker | 8 Apr 14:45 2014
Picon

new draft: draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node


A new draft has been posted, at
http://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node. Please take a
look at it and comment.

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

Mark ZZZ Smith | 7 Apr 23:21 2014
Picon

Fw: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt

Hi,

I've just posted the following ID, grateful for any feedback.

Regards,
Mark.

----- Forwarded Message -----
> From: "internet-drafts@..." <internet-drafts@...>
> To: Mark Smith <markzzzsmith@...>; Mark Smith <markzzzsmith <at> yahoo.com.au>
> Cc: 
> Sent: Tuesday, 8 April 2014 7:19 AM
> Subject: New Version Notification for draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> 
> 
> A new version of I-D, draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> has been successfully submitted by Mark Smith and posted to the
> IETF repository.
> 
> Name:        draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
> Revision:    00
> Title:        Further Mitigating Router ND Cache Exhaustion DoS Attacks Using 
> Solicited-Node Group Membership
> Document date:    2014-04-07
> Group:        Individual Submission
> Pages:        6
> URL:            
> http://www.ietf.org/internet-drafts/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node/
> Htmlized:      
> http://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-00
> 
> 
> Abstract:
>    For each of their IPv6 unicast or anycast addresses, nodes join a
>    Solicited-Node multicast group, formed using the lower 24 bits of the
>    address.  This group membership can be used by routers to further
>    mitigate the Neighbor Discovery cache Denial of Service attack.
> 
>                                                                                 
>   
> 
> 
> 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.
> 
> The IETF Secretariat
> 

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

Ole Troan | 7 Apr 10:35 2014

Re: I-D Action: draft-ietf-v6ops-64share-10.txt

shouldn't this document reference Appendix A of RFC4389 specifically?
if not also RFC4903.

cheers,
Ole

On 02 Apr 2014, at 1:14 , internet-drafts@... wrote:

> 
> 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           : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN link
>        Authors         : Cameron Byrne
>                          Dan Drown
>                          Ales Vizdal
> 	Filename        : draft-ietf-v6ops-64share-10.txt
> 	Pages           : 9
> 	Date            : 2014-04-01
> 
> Abstract:
>   This document describes requirements for extending an IPv6 /64 prefix
>   from a User Equipment 3GPP radio interface to a LAN link as well as
>   two implementation examples.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-v6ops-64share-10
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-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

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Alexandru Petrescu | 3 Apr 13:28 2014
Picon

Re: I-D Action: draft-ietf-v6ops-64share-10.txt

Thanks for the update.

I am happy this document advances.

I don't comment after a IESG review, just a few points for when time allows:

- the term 'mobile network' is inconsistently used across this document
   and a published RFC.
- the method works for _a_ SLAACed (W)LAN -  it wouldnt scale beyond
   one such link.

Alex

Le 02/04/2014 01:20, Vízdal Aleš a écrit :
> IESG review remarks have been incorporated.
>
> Ales
>
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@...] On Behalf Of
>> internet-drafts@...
>> Sent: Wednesday, April 02, 2014 1:15 AM
>> To: i-d-announce@...
>> Cc: v6ops@...
>> Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-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           : Extending an IPv6 /64 Prefix from a
>> 3GPP Mobile Interface to a LAN link
>>          Authors         : Cameron Byrne
>>                            Dan Drown
>>                            Ales Vizdal
>>        Filename        : draft-ietf-v6ops-64share-10.txt
>>        Pages           : 9
>>        Date            : 2014-04-01
>>
>> Abstract:
>>     This document describes requirements for extending an IPv6
>> /64 prefix
>>     from a User Equipment 3GPP radio interface to a LAN link
>> as well as
>>     two implementation examples.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-v6ops-64share-10
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-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
>
> Zásady komunikace, které společnost T-Mobile Czech Republic a.s. užívá při sjednávání
smluv, jsou uvedeny zde  http://www.t-mobile.cz/zasady. Není-li v zásadách uvedeno jinak,
nepředstavuje tato zpráva konečný návrh na uzavření či změnu smlouvy ani přijetí takového
návrhu. The communication principles which T-Mobile Czech Republic a.s. applies when negotiating
contracts are defined here http://www.t-mobile.cz/principles. Unless otherwise stated in the
principles, this message does not constitute the final offer to contract or an amendment of a contract or
acceptance of such offer.
>
> _______________________________________________
> v6ops mailing list
> v6ops@...
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

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

The IESG | 31 Mar 21:26 2014
Picon

Document Action: 'NAT64 Deployment Options and Experience' to Informational RFC (draft-ietf-v6ops-nat64-experience-10.txt)

The IESG has approved the following document:
- 'NAT64 Deployment Options and Experience'
  (draft-ietf-v6ops-nat64-experience-10.txt) as Informational RFC

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Joel Jaeggli and Benoit Claise.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience/

Technical Summary

This document summarizes NAT64 function deployment scenarios and
operational experience.  Both NAT64 Carrier Grade NAT (NAT64-CGN) and
NAT64 server Front End (NAT64-FE) are considered in this document.

Working Group Summary

The original discussion is derived from the presentation of
http://www.ietf.org/proceedings/82/slides/v6ops-5.pdf. Afterwards, it
was documented as draft-chen-v6ops-nat64-experience in Feb 2012. The
working group document is a report developed by several operators on
the use of a NAT64 between an IPv6-only mobile network and the larger
IPv4-only network.

The draft has been discussed at length and in detail. There are some
operators in the working group that have a problem with it because it
openly discusses the use of RFC 6052/6144-6147 IPv4/IPv6 translation
and RFC 4193 ULAs; they hold the viewpoint that translation and the
use of non-global address space is philosophically and operationally
problematic. For example, a matter dealt with in the draft in response
to working group discussion, it often sacrifices geolocation
information that is important to certain types of services. The
authors of the draft also point out that running a dual stack mobile
network is expensive for reasons specific to mobile networks, and view
the trade-offs as acceptable given the economics.

Document Quality

As specified in the abstract, the document is not a protocol or
procedure; it is a report of operational deployment and testing of a
NAT64 service between an IPv6-only mobile network and the larger IPv4
Internet as well as a NAT64 service in an IDC environment. This
testing includes the use of NAT64 CGN and NAT64 FE, its coexistence
with more traditional NAT44, Reliability, Availability, and
Maintainability issues, the transparency or lack of it regarding
source addresses, Quality of Experience, MTU issues, and ULA-related
issues.

Personnel

The document shepherd is Fred Baker. The responsible AD is Joel
Jaegli.

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

Brzozowski, John | 31 Mar 21:01 2014
Picon

Re: Facebook v6 deployment

Ted,

Parts of New England have started to see native IPv6 support deployed.  I
know you and others have been waiting patiently.

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 609-377-6594
o) 484-962-0060
w) www.comcast6.net
e) john_brzozowski@...
=========================================

-----Original Message-----
From: Ted Lemon <Ted.Lemon@...>
Date: Monday, March 31, 2014 at 11:44
To: Mikael Abrahamsson <swmike@...>
Cc: v6ops <v6ops@...>
Subject: Re: [v6ops] Facebook v6 deployment

>On Mar 31, 2014, at 10:48 AM, Mikael Abrahamsson <swmike@...> wrote:
>> Comcast is doing IPv6 on a wide scale. http://www.comcast6.net/
>> As far as I can tell, they now have the largest IPv6 deployment in the
>>world.
>
>Unfortunately, those of us who live in backwaters still have IPv4-only
>service, despite being connected via Comcast.   This is certainly the
>case where I live, and apparently also where Nalini lives.
>
>_______________________________________________
>v6ops mailing list
>v6ops@...
>https://www.ietf.org/mailman/listinfo/v6ops

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

Tim Chown | 31 Mar 17:26 2014
Picon

Re: Facebook v6 deployment

For a pretty recent and very positive update on Comcast on IPv6, see:


Tim

On 31 Mar 2014, at 16:23, Gert Doering <gert-BgGAxIuQBdJeoWH0uzbU5w@public.gmane.org> wrote:

Hi,

On Mon, Mar 31, 2014 at 07:44:21AM -0700, Nalini Elkins wrote:
The ISP to my home is Comcast.  Just saying.  Seems doubtful that they will go under since they seem to have a near monopoly in the US.

Comcast actually is one of the first really large ISPs in the world that
went to IPv6...

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-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tim Chown | 31 Mar 17:23 2014
Picon

Re: Facebook v6 deployment

On 31 Mar 2014, at 15:47, Bill Jouris <bill.jouris <at> insidethestack.com> wrote:

"...in places that matter tunnels are gone."

Perhaps you could share what, exactly, you consider "places that matter."  Is it simply that places which offer IPv6 end-to-end are the only places that matter?

Just for the edification of those of us living in places which, apparently, do not matter....

Perhaps one view is that the addition of IPv6 connectivity/addresses for most of the root name servers is a positive indication that IPv6 is robustly deployed, and therefore likely to be native end-to-end, "where it matters" ?

Indeed the position in access networks is patchy at best, else we'd not see Google at only 3-4% IPv6 access.  In that light, tunnelbroker.net and friends are very valuable.

I suspect also that there might be more IPv4-in-Ipv6 tunnelling out there than most would expect.

Tim

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Nabil Benamar | 21 Mar 18:09 2014
Picon

Re: Facebook v6 deployment

On Mar 21, 2014 5:07 PM, "Nabil Benamar" <benamar73-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Thank you Brian for sharing this valuable presentation !

On Mar 21, 2014 4:52 PM, "Brian E Carpenter" <brian.e.carpenter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Apologies if this is old news, but there is lots
of meat in this talk that Robert Watson just pointed me to:

https://www.dropbox.com/s/doazzo5ygu3idna/WorldIPv6Congress-IPv6_LH%20v2.pdf

Regards
   Brian

_______________________________________________
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

Gmane