Subject: [BEHAVE] comments on draft-wing-behave-learn-prefix-04

From: xuxiaohu 41208 <[email-masked]>
Date: Wed, 11 Nov 2009 11:29:45 +0900

Hi Dan,

If I remembered the minutes of the last Behave WG session during IETF75 correctly, Dave had suggested that we don't need to invent a new RA option for prefix64, instead, we can use the RA-compatible DHCPv6 option for prefix64 directly in the RA message. My rough understanding is he didn't recommend removing the RA approach. Misunderstood?

For the DNS mechanism, in case that the recuisive DNS server used by the IPv6 clients within the IPv6 site is not the one controlled by the IPv6 site network operator, but a DNS server located in the IPv6 Internet. Hence it is infeasible for that DNS server to offer the LIR prefix64. Is that correct?

As for the DHCP mechanism, it works well. However, if the IPv6 site network operator chooses RA for IPv6 address auto-configuration, is it reasonable to require him to enable DHCP just for a single purpose of obtaining prefix64.

Xiaohu

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Nov 2009 10:43:31 -0800

> -----Original Message-----
> From: xuxiaohu 41208 [mailto:[email-masked]] 
> Sent: Tuesday, November 10, 2009 6:30 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: comments on draft-wing-behave-learn-prefix-04
> 
> Hi Dan,
> 
> If I remembered the minutes of the last Behave WG session 
> during IETF75 correctly, Dave had suggested that we don't 
> need to invent a new RA option for prefix64, instead, we can 
> use the RA-compatible DHCPv6 option for prefix64 directly in 
> the RA message.

But we don't have such a mechanism.  During the week I talked
with and got email from Tony Hain ([email-masked]) and Bob
Hinden ([email-masked]) that they were interested in
standardizing such a DHCP container for router advertisements.

> My rough understanding is he didn't recommend 
> removing the RA approach. Misunderstood?

Until we have such a mechanism, we can't cite it.  I expect
it should be easy to create the document.  Once it exists, we
have the conundrum of three ways to accomplish the same thing
(DNS, DHCPv6, DHCPv6-in-RA).

> For the DNS mechanism, in case that the recuisive DNS server 
> used by the IPv6 clients within the IPv6 site is not the one 
> controlled by the IPv6 site network operator, but a DNS 
> server located in the IPv6 Internet. Hence it is infeasible 
> for that DNS server to offer the LIR prefix64. Is that correct?

Yes.  But in that case, the host isn't using a DNS64 and thus 
IPv6/IPv4 translation doesn't occur for the general case (the
"general case" being applications that perform DNS AAAA 
queries), and I agree it would fail for the "special case"
of applications that aren't doing a DNS query 
(which is what draft-wing-behave-learn-prefix is intended to
help with).

> As for the DHCP mechanism, it works well. However, if the 
> IPv6 site network operator chooses RA for IPv6 address 
> auto-configuration, is it reasonable to require him to enable 
> DHCP just for a single purpose of obtaining prefix64.

Well, it isn't stateful DHCP -- it's stateless DHCP; only
DHCPINFORM needs to be supported.  It's the same stateless
DHCP that would be in the Router Advertisements, in fact.

But I agree that if DHCP is not being otherwise used we
should not create a need for it, and that RA would be better.

Hopefully the three of you interested in the DHCP RA container
will get it cranked out this month.  :-)

-d

---

From: Dave Thaler <[email-masked]>
Date: Tue, 17 Nov 2009 20:14:01 +0000

> > DHCP just for a single purpose of obtaining prefix64.

DHCP is used for obtaining any other
information besides the address... DNS information, prefix64,
anything else for which the router isn't authoritative.
So there isn't a "single purpose" per se, it's for all other
purposes.  I can't imagine a site network operator not having
other information (like DNS information) to configure.

-Dave