Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt

From: <[email-masked]>
Date: Wed, 1 Jun 2011 09:01:23 +0000

Originally the idea was that the name is well-known for the entity that requires NAT64/NSP discovery. It could be e.g. an application or an OS. Hence there would be no need to discover the name - and the name + public IPv4 address would be arranged by said application/OS vendor.. But that approach might not be so nice for generic DNSSEC recursive resolvers to learn the prefix..

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Andrew Sullivan
> Sent: 01. kesäkuuta 2011 01:06
> To: [email-masked]
> Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-
> 00.txt
> 
> On Tue, May 31, 2011 at 09:36:35PM +0000, Christian Huitema wrote:
> >
> > I am clearly not looking at something configured via DHCP. There are
> > plenty of configuration parameters that are not dependent on the local
> > network. For example, my laptop is configured with the domain name of
> > my mail server. That name will not change as the laptop moves from a
> > coffee shop to the airport. Similarly, my SIP client is configured
> > with the domain name of the STUN/TURN server that is uses for NAT
> > traversal. The same SIP client could actually easily be configured
> > with the name of the "NAT 64 discovery server."
> 
> You seem to be arguing, then, that instead of applications themselves having a
> global well-known value that they know how to interpret (which is, from a DNS
> point of view, already worse than a single global one), we'll just have everyone
> set up their own?
> 
> 
> I guess this has the advantage that it's easier on the DNS (it's just one more of
> the usual lookups everyone is already doing), but it has the conspicuous
> disadvantage that if you don't already have this configured, you need to learn
> how.  I thought the point of this was supposed to be that it would work for the
> most naive user?  (I'm not trying to be argumentative.  I'm just trying to
> understand the use here, since I thought something more elegant than a well-
> known name was what we were going to use until I learned otherwise in
> Prague.)
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Jun 2011 09:11:54 -0400

On Wed, Jun 01, 2011 at 09:01:23AM +0000, [email-masked] wrote:

> Originally the idea was that the name is well-known for the entity
> that requires NAT64/NSP discovery. It could be e.g. an application
> or an OS.

If applications are going to do this independently, there is nothing
at all for us to standardize.  They should do what they want.  It is
only if there is an _inter_operability problem where we have something
to say.  What I heard in Prague was that some applications were
already planning to do this, and so it seemed to me that, if we're
going to get this kind of behaviour it would be better if everyone did
it the same way.

> application/OS vendor.. But that approach might not be so nice for
> generic DNSSEC recursive resolvers to learn the prefix..

This is one reason why it would be better if everyone did it the same
way: a DNS resolver that wants to provide DNSSEC or that wants to
provide this information to the applications on the platform could
learn the prefix quickly and easily.  Otherwise, the DNS resolver
library "vendor" will have to come up with its own heuristic.

I appreciate the problem about the ranges suggested for the IP address
to be returned.  Perhaps that is resolvable another way: waste one
real IPv4 address.

A

-- 
Andrew Sullivan
[email-masked]

---

From: <[email-masked]>
Date: Wed, 1 Jun 2011 13:28:35 +0000

Hi,

I prefer the well-known name approach if we have rough consensus for it.

Where can we then get one public IPv4 address, if IANA is out and IETF has only "invalid" addresses?

Donation from someone?-) 

	Teemu

> Sent: 01. kesäkuuta 2011 16:12
> To: [email-masked]
> > that requires NAT64/NSP discovery. It could be e.g. an application or
> > an OS.
> 
> If applications are going to do this independently, there is nothing at all for us
> to standardize.  They should do what they want.  It is only if there is an
> _inter_operability problem where we have something to say.  What I heard in
> Prague was that some applications were already planning to do this, and so it
> seemed to me that, if we're going to get this kind of behaviour it would be
> better if everyone did it the same way.
> 
> way: a DNS resolver that wants to provide DNSSEC or that wants to provide this
> information to the applications on the platform could learn the prefix quickly
> and easily.  Otherwise, the DNS resolver library "vendor" will have to come up
> with its own heuristic.
> 
> I appreciate the problem about the ranges suggested for the IP address to be
> returned.  Perhaps that is resolvable another way: waste one real IPv4 address.
> 
> A
> 
> >
> > 	Teemu
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of ext Andrew Sullivan
> > > Subject: Re: [BEHAVE] Next for
> > > draft-ietf-behave-nat64-discovery-heuristic-
> > > 00.txt
> > >
> > > > I am clearly not looking at something configured via DHCP. There
> > > > are plenty of configuration parameters that are not dependent on
> > > > the local network. For example, my laptop is configured with the
> > > > domain name of my mail server. That name will not change as the
> > > > laptop moves from a coffee shop to the airport. Similarly, my SIP
> > > > client is configured with the domain name of the STUN/TURN server
> > > > that is uses for NAT traversal. The same SIP client could actually
> > > > easily be configured with the name of the "NAT 64 discovery server."
> > >
> > > You seem to be arguing, then, that instead of applications
> > > themselves having a global well-known value that they know how to
> > > interpret (which is, from a DNS point of view, already worse than a
> > > single global one), we'll just have everyone set up their own?
> > >
> > >
> > > I guess this has the advantage that it's easier on the DNS (it's
> > > just one more of the usual lookups everyone is already doing), but
> > > it has the conspicuous disadvantage that if you don't already have
> > > this configured, you need to learn how.  I thought the point of this
> > > was supposed to be that it would work for the most naive user?  (I'm
> > > not trying to be argumentative.  I'm just trying to understand the
> > > use here, since I thought something more elegant than a well- known
> > > name was what we were going to use until I learned otherwise in
> > > Prague.)
> > >
> > > A
> > >

---

From: <[email-masked]>
Date: Wed, 15 Jun 2011 10:32:04 +0000

Hi,

One way to avoid defining static public IPv4 address here is to just have well-known name, and then make the client to discover the IPv4 address in use by doing A query in parallel to AAAA. Would that be fine (except double the number of queries)?

Best regards,

	Teemu

> Of ext [email-masked]
> Sent: 01. kesäkuuta 2011 16:29
> To: [email-masked]; [email-masked]
> > going to get this kind of behaviour it would be better if everyone did it the
> same way.
> >
> > to be returned.  Perhaps that is resolvable another way: waste one real IPv4
> address.
> >
> > A
> >
> > >
> > > 	Teemu
> > >
> > > > > laptop moves from a coffee shop to the airport. Similarly, my
> > > > > SIP client is configured with the domain name of the STUN/TURN
> > > > > server that is uses for NAT traversal. The same SIP client could
> > > > > actually easily be configured with the name of the "NAT 64 discovery
> server."
> > > >
> > > > interpret (which is, from a DNS point of view, already worse than
> > > > a single global one), we'll just have everyone set up their own?
> > > >
> > > >
> > > > this configured, you need to learn how.  I thought the point of
> > > > this was supposed to be that it would work for the most naive
> > > > user?  (I'm not trying to be argumentative.  I'm just trying to
> > > > understand the use here, since I thought something more elegant
> > > > than a well- known name was what we were going to use until I
> > > > learned otherwise in
> > > > Prague.)
> > > >
> > > > A
> > > >