Internet Area Meeting 03/23/2009 - 1300 - 1500 1. Agenda Bashing 2. Area Updates - Ralph Droms in new AD, replacing Mark Townsley - Need volunteers for co-chair of DHC - Numerous BoFs during the week + 6AI + MIF + NETEXT + LISP + SHARA - draft-atlas-icmp-unnumbered + was in IETF Last Call + Late IPR issues - draft-arkko-arp-iana-rules + Approved by IESG and in AUTH48 state 3. Tunneling (Touch) - Tunnel Issues ID Status + Pending revision + Determining relationship with tunneling security concerns ID + Townsley suggests combining the two documents + Krishnan agrees with combining them, but wants recommendations softened + Thaler doesn't care whether they are combined or not, worried about the editorial effort to combine if there is community apathy - Identification field ID + Hosts don't ensure uniqueness of ID within 2 MSL + Templin doesn't agree with premise that the ID field has no meaning outside of the 5-tuple + Touch defends position of limited meaning of ID field + Arkko agrees with premise of the draft, asks whether there is known uses of ID field for other purposes + Templin provides forward pointer to upcoming SEAL presentation + Draft updated to be on Standards Track, including some clarifications 4. SEAL (Templin) - Tunnels are widely used + Various examples + Introduce odd behavior such as MTU reduction and ICMP blackholing - Tunnel encapsulation reduces MTU - Path MTU feedback lost - Hosts expect 1500 MTU and robust Path MTU Discovery - SEAL: + Adds 4 byte encapsulation sublayer + Tracks MTU without Path MTU Discovery - Extends IP ID field to 32-bits - Reports fragmentation within tunnel - Nonce-protected error feedback - Compatible with variety of tunneling mechanisms - Ingress Tunnel Endpoint (ITE) + sets re-assembly limit + sets initial MTU estimate + performs fragmentation for packets larger than known tunnel MTU + teturns ICMP Packet Too Big for packets that are too large - Egress Tunnel Endpoint (ETE) + Provides fragmentation reports - ITE can use inner IP fragmentation - ITE caches MTU and returns ICMP feedback - All packets used as MTU probe - ETE reports fragmentation - Touch: asks for clarification on inner IP fragmenation function. Does not believe inner fragmentation should ever be used - Templin: Inner fragmentation needed for supporting nested tunnels - Touch & Templin agree that offline discussion is needed to clarify the need for inner fragmentation - Considers that unmitigated fragmentation is harmful - Managed (carefully) fragmentation is useful - In-The-Network fragmentation is NOT a misfeature - Thaler: Thinks a better approach is to allow single fragment re-transmission - Touch: Really no solution for fragment re-transmission - Austein: Large DNS reponses need fragmentation. Need to assess tradeoffs for fragmentation - Touch: SEAL essentially puts the updated Path MTU functionality into the tunnel - Daley: Is there firewall requirements specified? - Templin: Yes, this is needed - Arkko: draft is currently on the RFC Editor path as an individual submission. Solicits comment on interest within the community - Durand: Similar work in Softwires DS-Lite specification 5. DHCP and Router Advertisements (Narten) - Some operators wish to deploy IPv6 without any IPv6 RA's - Want single protocol mechanism for managing all configuration information - Tighter/centralized control over information - Minimize operational changes when moving from IPv4 to IPv6 - Already use DHCP in IPv4 - Define DHCPv6 Default Router option and On-link Prefixes option - Not intended for edge networks - Useful where operator controls all devices - DHCPv4 defined Default Router Option - IPv6 preferred not replicating information over multiple protocols - Only wanted to define DHCPv6 options on demand rather than replicating all DHCPv4 options - Need to listen to operator input on IPv6 deployment needs - Jabber question on size of operatos asking for this option - Droms: no information on operator size, but input raised on NANOG mailing list - DHCPv6 Default Router Option + Same semantics as IPv6 Router Advertisement + Rogue DHCP servers have similar impact as rogue RA's - Question: unclear that rogue DHCP servers are similar to rogue RA's - Narten: Conceptually the same threat - Krishnan: Assuming that RA's will still be processed on hosts - Narten: Yes, information is merged - DHCPv6 Prefix Information Option + Defines prefix, prefix length, valid lifetime, and preferred lifetime + Indicates which links are on-link - Durand: Is there an off-link indicator? - Narten: No. - Durand: Can you show a prefix that is off-link? - Droms: No use case seen at this point - Other options exist in RA's, are they needed in DHCPv6? - Need to work out timing for information timeout - Need to work out handling for overlapping information from DHCPv6 and RA - Impact on M&O bits - Jinmei: Does PIO only support on-link prefixes? If so, why do we need preferred lifetime? - Droms/Narten: Need to fix this in specification. - Sumita: Can we drop support of Default router in RA? - Narten: Shouldn't need any RA's for this deployment model. - Wasserman: Timing issues are important and need to be understood and modeled. - Daley: Not sure we should do this. Rogue RA's could impact this approach. Does the DHCPv6 option need to signal the level of service available from local router? - Touch: Not sure what benefits you gain from shutting off RA's. - Narten: Believes that there are complex networks that do not benefit from RA's. - Krishnan: Will IETF recommend one of these approaches as the preferred model? - Narten: Believes there will be an applicability statement for this approach. - Krishnan: What will happen if someone wants to turn off DHCP? DNS information is not provided in RA approach. - Narten: Different issue that can be raised separately. - Hankins: Draft has been implemented already. - Arkko: Sensitive to need of operators deploying IPv6. We need to know specific scenarios so that IETF understands the requirements. - Bush: Wants RA to be able to override DHCP option. - Durand: Likes the proposal and supports its development. - Miles: Not raised in the Broadband Forum. Doesn't think it is the right time to be making these changes. - Narten: Doesn't think this is a change. This approach does not change the behavior of the RA mechanism. - Thaler: Good presentation that clarifies some open issues. Observation that requirements listed in the presentation do not necessarily reflect what is in the protocol spec. Need to agree on the mechanism for follow-on options. - Chown: Unclear what the target environment actually is. May provide more flexibility for information dissemination. - Hinden: Needs more information on the target networks. Creates operational problem since all nodes on the network need to support this approach. If we do this in DHCP, then we will need to put additional information in RA's. - Narten: Agrees that this is a valid concern. - Austein: Thinks this approach is better late than never. This approach preserves the operators back-end systems. - Daley: Liveness check for routers is still needed. - Narten: That dictates operational behavior. - Unknown: As an operator, I support IPv6 with RA's and did not have to throw out the back-end systems. - Klein: Is the driver an issue with multicast messages? - Droms: NANOG survey did not indicate an issue with multicast usage. - Nordmark: Thinks it is a good idea. Unclear how to move forward with other options, different transports, resolution of overlapping information, etc. - Unknown #2: Wants feature parity between DHCPv4 and DHCPv6 options. - Arkko: Need to take this discussion to the list and get better discussion on the drivers and the approaches. - Krishnan: Pointing out that he wrote a spec on how to share options between DHCP and RA's. 6. Shared ISP Address (Nakagawa) - Double NAT and the address space is the same on both sides of the outer NAT - One solution is to allocate a new private space to be used by ISPs - Significant address space (/8) - What is the allocation process? - What is the IETF's strategic recommendation? - Is using 240/4 a possibility? - Not designed to push out IPv6 deployment - Still need reachability to IPv4 servers after IPv6 cut-over - Needed for dual-stack operation to allow IPv4 connectivity - Provides NAT444 service - Size of allocated block impacts usefulness for ISPs - Minimum limit: /10 - Use of 240/4 requires testing and replacement of some devices - Topic to be discussed in OPSAREA - Durand: Hates the proposal. Too big a price to pay. - Wasserman: Agrees with Alain that there are alternatives. Draft does not specify how the rules would be enforced (e.g., addresses won't be used on customer networks). - Arkko/Townsley: many issues in the spec that need to be worked out. - Cheshire: There are three private address ranges already. Provider than specify which one the customer uses. ISPs are not the only entities with this problem. - Unknown #1: Use 240/4 since the impact on changes is localized to ISP. - Daley: NAT444 will never be deployed in China. All IP stacks require change to support 240/4. Renumbering devices is more expensive than upgrading to IPv6. - Krishnan: Add functionality to home gateway to stop if the address range on both sides is the same. - Unknown #2: Similar proposal brought to ARIN and was voted down. - Chairs conclude the meeting.