Re: Next for draft-ietf-behave-nat64-discovery-heuristic-00.txt
<teemu.savolainen <at> nokia.com>
2011-06-15 10:32:04 GMT
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
> -----Original Message-----
> From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On Behalf
> Of ext teemu.savolainen <at> nokia.com
> Sent: 01. kesäkuuta 2011 16:29
> To: ajs <at> anvilwalrusden.com; behave <at> ietf.org
> Subject: Re: [BEHAVE] Next for draft-ietf-behave-nat64-discovery-heuristic-
> 00.txt
>
> 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
>
>
>
> > -----Original Message-----
> > From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
> > Behalf Of ext Andrew Sullivan
> > Sent: 01. kesäkuuta 2011 16:12
> > To: behave <at> ietf.org
> > Subject: Re: [BEHAVE] Next for
> > draft-ietf-behave-nat64-discovery-heuristic-
> > 00.txt
> >
> > On Wed, Jun 01, 2011 at 09:01:23AM +0000, teemu.savolainen <at> nokia.com
> > 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
> >
> > >
> > > Teemu
> > >
> > > > -----Original Message-----
> > > > From: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] On
> > > > Behalf Of ext Andrew Sullivan
> > > > Sent: 01. kesäkuuta 2011 01:06
> > > > To: behave <at> ietf.org
> > > > 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
> > > >
> > > _______________________________________________
> > > Behave mailing list
> > > Behave <at> ietf.org
> > > https://www.ietf.org/mailman/listinfo/behave
> >
> > --
> > Andrew Sullivan
> > ajs <at> anvilwalrusden.com
> > _______________________________________________
> > Behave mailing list
> > Behave <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave <at> ietf.org
> https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
Behave <at> ietf.org
https://www.ietf.org/mailman/listinfo/behave
RSS Feed