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

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Feb 2011 19:14:48 +0000

On our charter we have the following milestones for which there is no current WG document:
Apr 2011

Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std)

Apr 2011

Submit to IESG: NAT64 load balancing (std/info)

For the first milestone, the chairs believe there are two complementary drafts that together may meet the milestone.  These are:
draft-korhonen-behave-nat64-learn-analysis-01<http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-analysis-01>
(-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

http://tools.ietf.org/html/draft-wing-behave-dns64-config-02
(this was presented at IETF 77, see minutes at http://www.ietf.org/proceedings/77/minutes/behave.txt)

For the second milestone, there is:
http://tools.ietf.org/html/draft-zhang-behave-nat64-load-balancing-01
(-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

This email is to solicit WG feedback on whether to adopt each of the above documents as WG documents.
As a reminder, adoption as a WG document means there is consensus that the document is a good starting point
(but may still need work of course).

Please respond saying whether or not you support WG adoption at this time of each document under consideration above.

Thanks,
-Dave

---

From: John Border <[email-masked]>
Date: Mon, 14 Feb 2011 14:35:53 -0500

Would the first two be combined into a single document or will they remain separate?  Just curious...

    Either way, I am in favor of adopting all of them...

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Thaler
Sent: Monday, February 14, 2011 2:15 PM
To: 'behave' ([email-masked])
Subject: [BEHAVE] Call for WG adoption of several documents

Apr 2011

Thanks,
-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 14 Feb 2011 19:46:02 +0000

Dan and I had assumed they would remain separate if adopted,
but WG opinion on that would be good to hear too.

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Border
Sent: Monday, February 14, 2011 11:36 AM
To: 'behave' ([email-masked])
Subject: Re: [BEHAVE] Call for WG adoption of several documents

John

Apr 2011

Thanks,
-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Feb 2011 09:29:00 +1300

Hi,

> (this was presented at IETF 77, see minutes at http://www.ietf.org/proceedings/77/minutes/behave.txt)

I don't think either of these drafts is quite there yet. They both discuss
various solutions at some length, but neither of them is clearly proposing
a single solution to the stated problem. draft-wing- does express a
preference, but we haven't debated that.

Have we even debated whether the solution must work properly with
untouched RFC3484-conforming hosts? I'd be very hesitant about any
solution that *requires* host updates.

Also, I don't think either draft considers the case where a dual stack
host receives a NAT64-based IPv6 address via an application layer referral,
so that DNS is not part of the picture. Are we trying to solve that
case too?

I think I'd rather see a new draft that contains only one solution. The existing
drafts could then become informational background documents.

Don't we *also* need a solution to the main problem considered by
draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but
seems important.

> (-00 was presented last IETF, see minutes at http://www.ietf.org/proceedings/79/minutes/behave.txt)

If the goal is Informational, this draft is a good one to adopt.

   Brian

---

From: <[email-masked]>
Date: Mon, 14 Feb 2011 20:39:37 +0000

Hi,

We have set of explicit solution drafts out there, e.g. but not limited:
draft-korhonen-edns0-synthesis-flag-01
draft-savolainen-heuristic-nat64-discovery-00

The purpose of the draft-korhonen-behave-nat64-learn-analysis has been to compare various solutions and propose next steps.

In my opinion we might want to include content from draft-wing-behave-dns64-config to draft-korhonen-behave-nat64-learn-analysis, agree what is the best solution, write down the decision, and then also adopt some of the solutions.

It would be good to have the discussions now to progress before Prague.

My personal opinion, probably quite unsurprisingly, is that the "DNS Query for a Well-Known Name" (we will soon post update to draft-savolainen-heuristic-nat64-discovery that contains some updates learnt in discussions, like DNSSEC considerations) should be one and then additionally we might need an explicit solution as well (e.g. draft-korhonen-edns0-synthesis-flag). 

Best regards,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Brian E Carpenter
> Sent: 14. helmikuuta 2011 22:29
> To: Dave Thaler
> Cc: 'behave' ([email-masked])
> > For the first milestone, the chairs believe there are two
> complementary drafts that together may meet the milestone.  These are:
> > draft-korhonen-behave-nat64-learn-analysis-
> 01<http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-
> analysis-01>
> > (-00 was presented last IETF, see minutes at
> http://www.ietf.org/proceedings/79/minutes/behave.txt)
> >
> >
> > (this was presented at IETF 77, see minutes at
> http://www.ietf.org/proceedings/77/minutes/behave.txt)
> 
> > (-00 was presented last IETF, see minutes at
> http://www.ietf.org/proceedings/79/minutes/behave.txt)
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Feb 2011 15:58:21 -0800

> Behalf Of Brian E Carpenter
> Sent: Monday, February 14, 2011 12:29 PM
> To: Dave Thaler

In my mind, I view draft-wing-behave-dns64-config as solving the
problem when DNS is involved (that is, an application does a DNS 
query), and draft-korhonen-behave-nat64-learn-analysis as solving the
problem when DNS is not involved (that is, an application has an
IPv4 address literal).

draft-wing-behave-dns64-config suggests using an IPv4-mapped
IPv6 address as the first-priority DNS server.  I have not tested
many OSs with that configuration.  But it feels like it could work
pretty well.  The other techniques listed in 
draft-wing-behave-dns64-config are worse ideas, but listed for
completeness.  Those could be easily moved into an Appendix
or dropped from the document entirely.

> so that DNS is not part of the picture. Are we trying to solve that

draft-korhonen-behave-nat64-learn-analysis tries to solve that case
where an IPv4 address literal is obtained, and an IPv6-only host
wants to use it.  It analyzes a bunch of techniques and at the
end of the last IETF meeting we reached a rough consensus similar
to what Teemu just posted at
http://www.ietf.org/mail-archive/web/behave/current/msg09196.html,
namely that we use a heuristic for our immediate needs (doing a 
DNS query of a special name) and we build a standard for longer 
term (EDNS0).

> draft-korhonen- (learn NAT64 prefix)? That isn't in the charter, but

Learning the NAT64's prefix is the only way to solve the referral 
problem, where an IPv6-only host gets an IPv4 address literal and
wants to communicate with that host.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Feb 2011 13:16:06 +1300

> problem when DNS is not involved (that is, an application has an

Fair enough, if there's consensus on that.
> or dropped from the document entirely.

Fair enough too, if there's consensus, but the document would have to
read more authoritatively than it does now.

> where an IPv4 address literal is obtained, 

Yes. I'm asking about the opposite case, where IPv6-only host A gets a
synthetic IPv6 address and passes it over to dual-stack host B. If we
do nothing, B will just use that IPv6 address as-is and the result is
either redundant translation, or failure, depending on the details.
Maybe there's nothing we can do for that case, in which case we should
document it and move on.

and an IPv6-only host

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Feb 2011 17:02:18 -0800

> Fair enough, if there's consensus on that.

There probably isn't.  I expect many people have not read the
introduction of these two documents...  :-|

Hopefully this thread will initiate some discussion, along the
lines of "Yes, I have exactly that problem."

We (Cisco) have recently been having a lot more conversations with
operators that are wondering how to build a network comprised of
both IPv6-only hosts (which use a NAT64) and dual-stack hosts (which
might use a NAT44), so that the dual-stack hosts don't put traffic 
on the NAT64.  The working group has discussed this at meetings, but
I don't recall much in-depth discussion on the mailing list.  My
slides are at http://www.ietf.org/proceedings/77/slides/behave-12.pdf
(notably see slide #6), and I distinctly recall Andrew Sullivan pointing 
out that traffic that it costs the same to traverse a NAT44 or a NAT64,
which I agree.  The only true savings is if the network doesn't have a 
NAT44, such as depicted on slide 5, or of course if the application
simply breaks when traversing a NAT64 (but works when traversing a 
NAT44).

The question is:  for dual-stack hosts, do we want to avoid the 
NAT64?

> read more authoritatively than it does now.

Point taken.  Editing now.

> Maybe there's nothing we can do for that case, in which case we should

If it can, Host A should un-do the synthesis for passing along the
referral.  I don't know where that should be documented - grobj or
in a behave spec?

-d

> >> I think I'd rather see a new draft that contains only one solution.
> The
> >> existing

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Feb 2011 15:10:31 +1300

On 2011-02-15 14:02, Dan Wing wrote:

<snip>

> referral.  I don't know where that should be documented - grobj or

If A knows that B is dual stack, that would be appropriate. But if
A is a genuine 100% pure IPv6-only host, it knows *nothing* about
IPv4, in fact it doesn't know anything about NAT64 either, so it
can't know that it should desynthesize the address.

I don't see much future in specifying extra features for
NAT64-aware IPv6-only hosts. Do you see operating systems vendors
caring about that?

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Feb 2011 18:24:22 -0800

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, February 14, 2011 6:11 PM
> To: Dan Wing
> Cc: ''behave''; 'Dave Thaler'
> Subject: Desynthesis [was Call for WG adoption of several documents]
> 

I don't see how such an application could be 100% pure IPv6-only.

An application doing referrals with IPv4 peers (across a
NAT64) will need to handle IPv4 addresses.  That will remain
true until the number of IPv4 peers for that application is
miniscule.

> NAT64-aware IPv6-only hosts. Do you see operating systems vendors

Applications care.  And draft-savolainen-heuristic-nat64-discovery
allows applications to learn the NAT64's prefix without 
cooperation or support of the underlying OS.

-d

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 Feb 2011 18:25:55 -0800

I have considered use cases  where nat64 is the preferred transition
mechanism and ds-lite is used as a stop-gap mechanism for legacy apps and
dns64 drives all possible traffic to the nat64. Therefore, I really don't
think there is value is trying to be too smart and work around the nat64. If
there is a nat64 in the network, the network operator put it there
purposefully and expects it to be used.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Feb 2011 15:37:52 +1300

Dan,

> true until the number of IPv4 peers for that application is

That's certainly true of some applications. I was thinking of the
network stack.

> cooperation or support of the underlying OS.

OK, but does that imply work in this WG?

   Brian

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 14 Feb 2011 18:41:30 -0800

> The question is:  for dual-stack hosts, do we want to avoid the

No. The network operator controls the DNS server and will provide dns64 as
needed. That is the simplest answer and therefore likely the best.

If, by design or not, a ds host gets dns64 not much is lost.  In the
networks where dns64 is most relevant nat44 is generally used as well.

Cb

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Feb 2011 00:38:54 +1100

In message <[email-masked]>, Came
> purposefully and expects it to be used.

NAT64 could also be there for those hosts that don't yet support
DS-Lite.  As a mechanism to connect to IPv4 hosts DS-Lite does a
better job than NAT64 can ever do.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 15 Feb 2011 06:04:11 -0800

> better job than NAT64 can ever do.

Seems like an opinion based on criteria .... any network operator want to
claim this use case as valid?

I think ds-lite is generally seen as a home gateway solution.  I am not sure
it will ever be in a deployment race with nat64

My only point is that a lot of the transition design is based on supporting
the as-is ecosystem.  Changing the ecosystem and host behavior to fit the
transition mechanism can be dangerous and in a real use case destructive to
operator intent. It is changing the rules of the game, which sometimes makes
sense, but there should be strong consensus reached before attempting such
changes in the ietf

Cb

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Feb 2011 01:40:21 +1100

In message <AANLkTikb5keEKdi0OibvvS-j2=qWJhYEn6mkfJ=[email-masked]>, Came
ron Byrne writes:
> --0015175cd330805458049c52a34b
> Content-Type: text/plain; charset=ISO-8859-1
> 

NAT64 of often deployed as it is the only thing which will "work"
to provide access to the legacy network given the contraints of a
IPv6 only network and hosts which may or may not support DS-Lite.

With a little bit of ingenuity the operators could support DS-Lite
capable hosts by looking for ds-lite dhcp option and returning non
DNS64 servers along with the AFTR's address.  This would result in
less breakage at the cost of running different types of LSN instead
of multiple LSN's of the same type.

Mark

---

From: <[email-masked]>
Date: Tue, 15 Feb 2011 16:03:56 +0100

Dear Dave, all,

IMO, draft-korhonen-behave-nat64-learn-analysis<http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-analysis-01> should be the place where issues about NAT64/DNS64 are analysed. Solution-related I-Ds are to be considered once the recommendations of draft-korhonen-behave-nat64-learn-analysis<http://tools.ietf.org/html/draft-korhonen-behave-nat64-learn-analysis-01> are frozen.

BTW, I re-iterate my suggestion to include a section about draft-carpenter-behave-referral-object in the analysis document.

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Dave Thaler
Envoyé : lundi 14 février 2011 20:15
À : 'behave' ([email-masked])
Objet : [BEHAVE] Call for WG adoption of several documents

Apr 2011

Thanks,
-Dave

********************************************************************************

IMPORTANT. 
Les informations contenues dans ce message électronique y compris les fichiers attachés sont strictement confidentielles et peuvent être protégées par la loi.
Ce message électronique est destiné exclusivement au(x) destinataire(s) mentionné(s) ci-dessus. 
Si vous avez reçu ce message par erreur ou s'il ne vous est pas destiné, veuillez immédiatement le signaler à l'expéditeur et effacer ce message et tous les fichiers éventuellement attachés.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. 
Tout message électronique est susceptible d'altération.
A ce titre, le Groupe France Télécom décline toute responsabilité notamment s'il a été altéré, déformé ou falsifié ; de même, il appartient au destinataire de s'assurer de l'absence de tout virus.
  
IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure of this message is prohibited. 
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified; additionally the recipient should ensure they are actually virus free.

********************************************************************************

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Feb 2011 10:30:18 -0500

> DNS query of a special name) and we build a standard for longer 

I'm not sure how I overlooked that consensus, but if you want my
opinion, step 2 is a waste of time.

Once there is standardisation around looking up a special name, that
has to be supported forever.  Therefore, there is no reason at all to
add the EDNS0 option: it just adds complexity without any benefit.
There is no fast-track approval for EDNS0 option codes yet, so this
objection is bound to be raised once the EDNS0 tactic comes up for
discussion.  So I would suggest that the well-known name trick (which,
for the record, makes my skin crawl) has to be the permanent plan if
you're going to adopt it.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Feb 2011 10:49:16 -0500

> The question is:  for dual-stack hosts, do we want to avoid the 

I don't get why these dual-stack hosts are getting the DNS64 as their
resolver.  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'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.

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.

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.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Feb 2011 07:49:20 -0800

> Sent: Monday, February 14, 2011 6:38 PM
> To: Dan Wing
> Cc: ''behave''
> Subject: Re: Desynthesis [was Call for WG adoption of several
> documents]
> 
> Dan,
> 
> >>>> Yes. I'm asking about the opposite case, where IPv6-only host A
> gets
> >> a

In that case, the application needs to know something about
the synthesized address, and de-synthesize.  Or else the 
referral will only work if the same synthesis occurs at the 
next host, at the next host, etc.  I don't see a way to
make it work without awareness of the synthesis and de-synthesis.

> OK, but does that imply work in this WG?

Learning of the NAT64's prefix belongs in BEHAVE, because NAT64
is BEHAVE's fault.  I dunno about referral-related stuff, though,
because it's the fault of applications.

-d

---

From: <[email-masked]>
Date: Tue, 15 Feb 2011 16:00:16 +0000

> getting synthetic responses from the DNS would be useful, but that's

In addition to learning an address is synthetic, there is one important (IMHO) reason to learn the prefix: hosts that implement validating DNS resolvers and are in IPv6-only NAT64 setup must be able to learn the prefix. Otherwise they cannot synthesize IPv6 addresses after validating A replies.

	Teemu

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Feb 2011 11:03:07 -0500

> In addition to learning an address is synthetic, there is one important (IMHO) reason to learn the prefix: hosts that implement validating DNS resolvers and are in IPv6-only NAT64 setup must be abl…

Yes, exactly.  (I guess it wasn't clear from what I was saying, but
this is just what I was thinking of.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Feb 2011 08:30:27 -0800

> Behalf Of Andrew Sullivan
> Sent: Tuesday, February 15, 2011 7:49 AM
> To: [email-masked]
> resolver. 

One physical network with two hosts:  an IPv6-only host (which
require a NAT64 to access the IPv4 Internet) and a dual-stack
host.  

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
> 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

Agreed.

> of the cases where this will really matter.

Ok.

> 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

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 15 Feb 2011 09:37:09 -0800

> require a NAT64 to access the IPv4 Internet) and a dual-stack

Where does this use case arise?

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?  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.

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Feb 2011 09:51:25 -0800

> 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.

> 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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Feb 2011 10:41:52 +1300

Mohamed,

> BTW, I re-iterate my suggestion to include a section about draft-carpenter-behave-referral-object in the analysis document.

Not that draft please - we are on draft-carpenter-referral-ps (problem statement only) now.

   Brian

> ------------------------------------------------------------------------
>