Behave WG Interim conf call 8/19/2009 Attendees -------------- Dan Wing (chair) Dave Thaler (chair) Agnes Tow Andrew Sullivan Bo Zhou Congxiao Bao Dapeng Liu Fred Baker Gabor Bajko Gang Chen Hui Deng Iljitsch van Beijnum John Leslie Marcelo Bagnulo Phil Roberts Suresh Krishnan Xing Li Zhen Cao Dong Zhang Notes taken by Dave Thaler draft-wing-behave-learn-prefix-03: Dan Wing --------- Dan presented his draft on learning the IPv6 prefix(es) used with IPv6/IPv4 translation. There was consensus on the case for the DNSSEC use, and for the address selection use, for learning the prefixes, but there was some disagreement about the use case for multicast and for IPv4 literals in URLs. Most of the discussion focused on the solution alternatives: DNS vs DHCP vs RA. Dave Thaler posted arguments for DHCP to the list last week, and summarized that posting during the call (essentially: DHCP requires no server changes for popular DHCP servers today, no client changes for Windows at least, and is consistent with IETF guidance on host configuration). Iljitsch summarized the argument for DNS, which is that Mac OSX doesn't support DHCPv6, and Linux doesn't have the API support that Windows has; also that not all IPv6 environments might have DHCPv6 relay functionality in routers whereas DNS can go across multiple hops. There was consensus that RAs were the most problematic, since they required routers to change (unlike DNS and DHCP where servers already support new records and options, Fred noted that routers today often cannot be configured with arbitrary RA options), and it would require many routers to be configured rather than a small number of DNS or DHCP servers, and this is especially problematic when the last hop routers are in a different network (or managed by a different organization) than the one running the translator. Still there was some interest in the possibility of a generic RA option container for DHCP options, as discussed in IntArea in IETF 74. It was acknowledged that applications could implement a simple protocol (RA or DHCP INFORM messages) to work around limitations in client stacks that don't have APIs for new options. Eventually those in the meeting got consensus to take the RA option off the table, but to keep both a DNS and a DHCP solution in the doc. MTU/Fragmentation Issues: Iljitsch van Beijnum ---------- The standard mechanism in RFC 2460 is that if a PktTooBig error comes back to a host with a size <1280, the host will send 1280 byte packets with a FragHdr, and the translator will take the presence of the FragHdr to set DF=0 in IPv4 packets. Iljitsch mentioned 3 cases where a black hole can arise: 1) If a host just sends 1280 byte packets without ever adding a FH, which would be an RFC violation. The feedback was that there's a small number of host stack implementations, and they get TAHI etc testing which verifies RFC compliance with this requirement, so this is not a very interesting case. 2) If the IPv6 network filters ICMPv6 messages (namely PktTooBig messages) traveling from the IPv6/IPv4 translator towards the IPv6-only host. 3) If the IPv4 network filters ICMPv4 messages (namely FragNeeded messages) travelling from the IPv4-only host towards the IPv6/IPv4 translator. There was some discussion on how likely the above scenarios were and whether this was a problem in practice, or only in theory. Currently the attendees had no data that this problem occurs in practice (any more than the normal case which is no different with translation). If this turns out to be an issue worth considering, there are multiple ways to solve this: 1) Keep things the way they are now, which puts pressure on getting the problems fixed 2) Have the NAT64 set DF=0 if the packet is <=1280 bytes, regardless of whether a FragHdr is included 3) Same as 2, but also have the NAT64 send PktTooBig messages with a minimum of 1280 (so IPv6 hosts will never add a FragHdr as a result of following the RFC rule) 4) Do reassembly and fragmentation in the translator 5) Change transport protocols, a la RFC 4821 which isn't implemented on most hosts today Iljitsch proposed letting implementers choose between 2 or 3. The 4th option was brought up by Zhen and Fred who argued for it. There was some discussion about the problem also occurring (if it occurs at all, that is) with stateless translation not just stateful, and having a common solution may be better than a stateful-specific solution. Options 1, 4, and 5 apply to both. Iljitsch explained that stateful translation (actually 1:N translation) requires the translator to do IPv4 id allocation itself, to ensure uniqueness across flows from all the IPv6 nodes that share the same IPv4 translation address, and hence the id in the FragHdr isn't used. In contrast, stateless translation requires the client to ensure that the id in the FragHdr is unique since fragments could flow through different translators. So in theory different solutions could apply. There were multiple people (not Iljitsch) arguing for a common solution being better, but Iljitsch pointed out that option 2 is a one-line change in a NAT64. Further discussion is needed on the list. Translation in the host (phone): Hui Deng ---------- The mobile network operator scenario is two hosts on an IPv6-only network communicating using IPv4-only applications, and you want the traffic to flow directly between the hosts rather than through some type of remote concentrator. Hui mentioned that on mobile phone platforms, it is easier to modify the host network stack than it is for other types of hosts. Dual-Stack Lite targets a similar scenario, but at the expense of having a central tunnel concentrator for IPv4 traffic, which the operator is trying to avoid. To solve this scenario using tunneling (without a central tunnel concentrator the operator is trying to avoid), it would require a host-to-host IPv4-over-IPv6 protocol, for which none exists. ISATAP and 6to4 are examples of protocols that do host-to-host IPv6-over-IPv4 tunneling, but there's no equivalent for IPv4-over-IPv6. Dan Wing asked how one application would get the IPv4 address of another host in this scenario, when there's more hosts in the network than can be represented in the available IPv4 space. The answer was that DNS or whatever other mechanism is used needs to use the IPv6 address for uniqueness (e.g., AAAA queries in DNS), and the resolving host then has to locally synthesize an IPv4 address for that destination and maintain an internal mapping table used for translation. So the IPv4 address returned to the resolving application is only unique and usable within that host. At this point time was up, and further discussion was deferred to the list and/or the next conf call. The next interim conf call will be held the same time (7am Pacific Daylight Time) September 16th.