Sunset4 Working Group Meeting Agenda IETF 85, Atlanta, GA, USA November 2012 - Administrativia Christopher Liljesntolpe - etherpad scribe - New Charter revision http://www.ietf.org/mail-archive/web/sunset4/current/msg00094.html http://www.ietf.org/proceedings/85/slides/slides-85-sunset4-0.pdf [chairs] explicit exclusion of NAT444 in charter new proposed charter was seen but not officially reviewed or agreed by IESG New Charter proposal - Gap analysis - Provisioning methods to signal dual-stack host to disable use of IPv4 - NAT64 setup and provisioning Discussion No speakers Oppose new charter approval: - Gap Analysis for IPv4 Sunset http://tools.ietf.org/id/draft-ietf-sunset4-gapanalysis  [Simon P] adopted as wg draft since IETF84 and integrated new ideas from Cathy Zhu New section: On-Demand provisioning of IPv4 Addresses - see slides Are we done with the draft? [Lee Howard] several points in the draft with one protocol telling a host if another protocol is available or not. - may actually be a reference to the next draft. Ignore this comment. [Ralph Droms] What was the methodology to determine list (experiments, exhaustive discovery) [Simon P] - brain storming. Interest in more experimental work. We run IPv6-only and extracted some findings. [Chairs] - request more reviews from WG - volunteers were asked for: Lee Howard, Tom Taylor, and Nejc Skoberne - Turning off IPv4 Using DHCPv6 http://tools.ietf.org/id/draft-perreault-sunset4-noipv4 [Simon P] Split the "v4-level" value "1" into two  1 - no IPv4 upstream 2 - no IPv4 upstream, and restricted downstream Should DHCPv4 option be included? [Lee Howard] - talking to the gap analysis slide - believes that his point still stands as above. Host v4 instance has no idea if a DHCPv4 host [Ted L] - We don't need this - it's a tool to create havoc and attack vectors [Chris L] - OS should be able to turn off value '2' behavior. [Dave Thaler] - An option to just hint to not wake up to try DHCPv4 - rather than turn off v4. Also, MUST behavior on interface "heard" on, but SHOULD or MAY on other interfaces. [Mark T] - Retry backoff rather than turn off IPv4. [Ted L] - Can use reconfigure. Dave's suggestion better than what is in the draft. Create two options, one a MUST and one a SHOULD. [Stuart C] - We had appletalk, and we didn't need a DHCP option to make it go away, it just went away [Chris L] - value "2" is best done via other management tools [Bob Hinden] = Disagrees with Chris L [Tianle Yang] - Study in the network - two types of users, dual-stack and IPv6 only. The IPv6 only users still have dual-stack behaviors and generate IPv4 traffic. This causes issues with useless traffic in the v6 only network. [Ted L] - on the idea for a "you can use v4, but v6 will be sufficient" have DHCPv4 server run slower, and not respond at all if a DHCPv6 response is seen. [Lee Howard] - Use happy eyeballs to make the v4 and v6 decision rather than this new "hint idea" [Wes George] - We need semantics to weight IPv4 vs IPv6 [] - Better for host to return v4 address if it is not in use [Mark T] - Thinking about Happy Eyeballs - What we want to be able to do is tell Happy Eyeballs that this path will take you on a high-cost path, rather than this other path which is "cheaper". We need a feedback mechanism in happy eyeballs. There is a bigger, wider question, like in TCP, drop the packet, cause backoff, etc. based on network utilization. [Cameron] - There needs to be a way for the client be told to use a v6 path. Supporting Mark T. Common scenario is IPv6 traffic and NAT44.  We have elements that optimize locally, rather than globally. There needs to be a way for the network provider to signal resource utilization [Dave T] - This is a fairly narrow use case. How about signaling if traffic will go through a NAT (either NAT44 or NAT64) rather than v4 vs. v6. {Rob from BT] - Seems to be encouraging things to go the right way. +1 on influencing Happy Eyeballs. Doesn't want to scale CGNAT. Would like to limit the use of those NAT behaviors. [Dave T] - Incentives need to aligned between hosts and resources. This solution is targeting OS's and stacks, not Apps. [Mark T] - and because they are not aligned, this will be more difficult. If every host on the network behaved selfishly - the network would melt. The use of packet drop acted as a feedback loop.  We need the same for consumption of NAT tables. [Dave T] - interjection - "won't happen until there is a bad experience" Back to [Mark T] - we need the same kind of signal. [Eric N] - crazy idea - ICMPv4 message? [Chris L] - +1 to Eric's idea [Lee H] - remember we have active participants Working group adoption? [Chairs] - not a milestone. New charter would cover this. Call for WG adoption after the adoption of the new charter. What would we do with the three drafts that are somewhat related. - Weakening Aggregated Traffic of DHCP Discover Messages http://tools.ietf.org/id/draft-yang-sunset4-weaken-dhcp http://www.ietf.org/proceedings/85/slides/slides-85-sunset4-1.pdf [Tianle Yang] presenting. Wei meng : dual-stack supported, how about ipv4? - etherpad fell off the net for a few minutes [Ted L] - Recollection faint but seemed to be in conflict to the NoIPv4 document. So DHC preferred for the documents to be discussed in one place before DHC issued a position.  DHC has no standard for what to do if DHCP is not on the network [Bob H] - When there is NO IPv4 configured - it's a broader problem - DHCP is not the only protocol that is used for discovery. We should turn off everything, and not just DHCPv4 discovery. [Tina T] - Offline conversation - what additional text is required if NoIPv4 is used as the starting point.  Move the testing data to a seperate informational draft [Stuart C] - If I was a network operator I would have a DHCP server that issues the same IP address to all hosts with a 24 hour lease. That would stop the re-query. Then that address can be used as a sentinal address [cz] - Valuable - see more trials for both this an NoIPv4. It also improves dhcpv4 w.r.t. unspecified behavior [Ralph D] - responding to Stuart - part of the side-effect is to not have IPv4 at all to affect other applications from trying IPv4. [Stuart C] - We need to experiment with what would work (subnet without a router, link local, etc) - Graceful IPv4 Sunset with Traffic Migration http://tools.ietf.org/id/draft-chen-sunset4-traffic-migration http://www.ietf.org/proceedings/85/slides/slides-85-sunset4-3.pdf [Gang Chen] presenting [Lee Howard] - Hearing the need for a way to "Steer" traffic between v4 and v6.  It is an interesting charter question to see if it is in charter to do that steering. [Simon P] - Why tell the clients what transition mechanism you are using? [GC] - 4RD and similar is, by default disabled - we need a way to turn those functions on. [Simon P] - and this option won't be turned off as well by default? [Chairs] = we have 3, 4, no 5 ways, - the three drafts - Stuart's weird addresses How many have read all the documents A hum may identify a strong yes or no. DHCPv6 - push IPv4 usage: DHCPv6 - pushing DHCP delay number: DHCPv6 & PCP: Stuart's "weird" addresses: No conclusion. [Chairs] - the following two are probably out of scope if the IESG agrees with the new charter.  May be individual or AD sponsored. - Managed Objects for Carrier Grade NAT (CGN) http://tools.ietf.org/id/draft-perreault-sunset4-cgn-mib [Simon P] presenting [Chairs] - putting AD's on the spot - What do we do if the charter is changed [Ralph D] - I don't have a good answer on this until the IESG reaction to the charter is known. - Stateless IPv4 Network Address Translation http://tools.ietf.org/id/draft-tsou-stateless-nat44 http://www.ietf.org/proceedings/85/slides/slides-85-sunset4-2.pdf [Will Liu] - presenting [Lee H] - I'll make the obligatory sigh "not another transistion statement". My technical concern - I don't understand the state where I would make CPE change, why not just going to IPv6? [Will Liu] - yes we gave you another choice that doesn't make much change [Lee H] - I don't need another one [Nejc Skoberne] - It's IPv4 life support. The IETF shouldn't endorse something that does not drive transition. [Chairs] - The NAT44 charter change would clearly prohibit this work.