Re: [BEHAVE] Call for WG adoption of several documents

["Dan Wing" <[e-mail]>]

> > One physical network with two hosts:  an IPv6-only host (which
> > require a NAT64 to access the IPv4 Internet) and a dual-stack
> > host.
> 
> Where does this use case arise?

It's a natural transition from IPv4-only to the eventual end-game, which 
is IPv6-only:

  1. IPv4-only ("today"), possibly with NAPT44
  2. dual-stack ("tomorrow"), possibly with NAPT44.  Adding
     IPv6 to the network, or adding a dual-stack host, has 
     absolutely no effect on existing IPv4-only hosts (1).
  3. IPv6-only ("day after tomorrow"), with stateful NAT64 and 
     likely with NAPT44.  This requires adding DNS64 to the
     network.  This has an effect on existing dual-stack
     hosts (2), because their traffic will immediately start
     traversing the NAT64.

Best way to think of this is a University network, where students
are connecting to the network and expect it "to just work".  As 
soon as the network begins supporting IPv6-only (3), by deploying
a DNS64+NAT64, it causes an immediate change to how their 
dual-stack hosts function.

This may impair the successful deployment of DNS64+NAT64, and
thus may impair the successful deployment of IPv6-only hosts.

> It's not in mobile, different classes of users have different APN
> settings which have different DNS servers.  The network has a high
> degree of control of who gets which DNS server.
> 
> Is there not similar control in  xDSL, FTTH or DOCSIS networks?
> DHCPv6 controls and scopes? 

It's a network with two hosts:  one dual stack and one IPv6-only.
Conceptually it's an Ethernet network with two hosts.

> If these controls for network operator
> policy already exist, it seems better to use those as they already
> exist and are a known way of controlling who gets which DNS server.
> 
> It seems like the easiest way to do this with a broad brush is to make
> the IPv6 DNS64 server only available over IPv6 and the straight DNS
> server available on IPv4, and end host configure as needed via
> whichever means are relevant in that network.

Sure.  And that is exactly what draft-wing-behave-dns64-config-03
suggests:

  "For example, a dual-stack host and an IPv6-only host would be
   configured with the following DNS servers, in this order, where the
   first one is the normal DNS server (192.0.2.1) and the second one is
   the DNS64 server (2001:db8:dddd::1234)

                ::ffff:192.0.2.1       # 'normal' DNS server
                2001:db8:dddd::1234    # DNS64 server
   "

-d

> I am just trying to be practical about where this work is relevant,
> specifically around the questionable notion of avoiding NAT64 in favor
> or NAT44.
> 
> Cameron
> 
> 
> > The scenario is a network that wants/needs IPv6-only devices
> > (perhaps for testing, perhaps for real deployment), but --
> > critically -- does not want to disrupt or disturb their
> > existing dual-stack hosts.
> >
> >> The only case I've heard so far is something to do with
> >> some complicated (and frankly, a little artificial) case where one
> >> group of network interfaces is really dual-stack, and the other
> group
> >> is actually NAT64, and you can't tell the difference up in the
> >> application layer and you pick the wrong one.
> >
> > That would be über nasty.  I had not heard that use-case.
> >
> >> That's not a problem we
> >> can solve: it's a MIF problem, and just a special case of the
> general
> >> problem that if you're in multiple networks and they have different
> >> networks available, you have a hard problem.
> >
> > Agreed.
> >
> >> On top of this (and this is the point Dan remembers), a lot of this
> >> talk is as though you have a pure, unmolested, IPv6 and IPv4 dual
> >> stack view, and then the nasty IPv4+NAT64 view.  But that's almost
> >> never going to be true in the cases we care about: most of the time,
> >> the IPv4 connectivity is already NAT44, and you need a very
> compelling
> >> case for why we need to make this giant NAT64 hairball even fuzzier
> in
> >> order to prefer a NAT44 to a NAT64.  The compelling case boils down
> to
> >> "protocols with IPv4 literals embedded in them."  I find it very
> hard
> >> to believe that we are going to fix that generic problem well enough
> >> that the better answer won't be "application gateway" every time.
>  We
> >> know how to build and ship the latter today.
> >>
> >> I don't think we should be adding elliptics, epicycles, and
> eccentrics
> >> to this already complicated NAT cosmology to solve the tiny
> percentage
> >> of the cases where this will really matter.
> >
> > Ok.
> >
> >> I do think that having a way for applications to learn that they're
> >> getting synthetic responses from the DNS would be useful, but that's
> >> because over in DNS land we're already trying to build new PKIs on
> top
> >> of DNSSEC (see the DANE WG), and I'd hate for that all to break the
> >> moment someone is stuck behind a NAT64.
> >
> > That's a vote for a solution in draft-korhonen-behave-nat64-learn-
> analysis.
> >
> > I saw your other note about skin-crawling with a DNS name.  :-)  Will
> > follow up on that separately.
> >
> > -d
> >
> >> A
> >>
> >> --
> >> Andrew Sullivan
> >> [e-mail]
> >> Shinkuro, Inc.
> >> _______________________________________________
> >> Behave mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/behave
> >
> > _______________________________________________
> > Behave mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/behave
> >