Subject: [BEHAVE] Notes from interim conf call 8/19/2009

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Aug 2009 18:32:04 +0000

Please send any additions/corrections.

-Dave

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

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 end up 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 (and doesn't apply to stateless).

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.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Aug 2009 20:44:20 +0200

> in a NAT64 (and doesn't apply to stateless).

Actually option 2 does work with stateless translation to some degree.  
It does fix the black hole, but if the black hole was otherwise  
present, there is no identification value from the IPv6 fragment  
header, so the translator has to come up with one itself, and run an  
increased risk of incorrect reassembly because of that. However, with  
option 1 the packet would be sent with DF=1 and not make it to the  
other side at all.

In the case where the fragment header is present as required by the  
RFCs, there is no difference between options 1 and 2.

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 21 Aug 2009 09:36:20 +0800

> DNS and a DHCP solution in the doc.

Will this consensus make the same regret in the future as the lack of DNS
option in RA or the lack of default route option in DHCPv6?  That's to say,
those users who use RA for IP auto-configuration would have to use another
solution just for the purpose of obtaining the prefix64.

Xiaohu

---

From: Chen Gang <[email-masked]>
Date: Thu, 27 Aug 2009 00:21:31 +0800

2009/8/21 Dave Thaler <[email-masked]>

> DNS and a DHCP solution in the doc.

With regard to choose RA or DHCP to convey prefix information, there are
some concerns that RA is more widely used approach to assign prefix
information to UE comparing to DHCP in mobile network. And 3GPP take RS/RA
as primary way to configure UE, since RS/RA  has widely implemented in host
v6 stacks. In some case, the network only support RS/RS. For example, GPRS
don't support DHCPv6 but RS/RA. So, the proposed solution will extend their
applicable scope when we use RS/RA.

-Gang