Subject: RE: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to supp ort DSTM envir onments

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 14 Jan 2002 08:18:52 -0600

Jim:

The client would send a DSTM option with the IA option encapsulated inside the DSTM option. The client need not send the IA Addr option if there are no addresses associated with the IA.

The -22 draft has the DSTM option encapsulating the IA option - the DSTM option is the outermost option.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Sunday, January 13, 2002 1:27 AM
To: Bernie Volz (EUD)
Cc: '???'; ngtans????; DHCP????
Subject: Re: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to
support DSTM envir onments

Bernie,

So the client could send in a request

IA
DSTM Option
IA Address Option (empty)

To the server that sent the Reconfigure.
As one way to implement the behavior.

The IA is still valid.

regards,

/jim

On Sun, 13 Jan 2002, Jim Bound wrote:

> Hi Bernie,
> 
> Our readings are not similar.  The server does not have to send addresses
> back with an advertise but just ack the IA.
> 
> In 17.2.2  it says:
> 
>    The server MUST include IA options in the Advertise message
>    containing any addresses that would be assigned to IAs contained in
>    the Solicit message from the client.  The server MAY include some or
>    all of the IA options from the client in the Advertise message.
> 
>    If the server will not assign any addresses to IAs in a subsequent
>    Request from the client, the server SHOULD either send an Advertise
>    message to the client that includes only a status code option with
>    the status code set to AddrUnavail and a status message for the user
>    or not respond to the Solicit message.
> 
> In the first paragraph the IA refers to the Identity Association Option.
> Not the IA Address Option.  The wording is correct in the spec.  IA by
> itself is a reference to the IA option as defined in 22.3.  If you then
> look at 22.4 it references the IA address option specifically.  So IA is
> the association (e.g. IAID, T1 and T2, etc.)   To reference the addresses
> for an IA we say specifically IA Address Option as in 22.4.
> 
> Hence the server MUST return the IAs but may not return addresses and it
> can too.  The spirit of this was to provide in dhcpv6 the optimization the
> working group requested so the client could get addresses after solicit
> from the server.  But the server policy can be that the client must do a
> request to get addresses unless it states specifically ADDRUNAVAIL for a
> specific IA (association again).
> 
> On Sat, 12 Jan 2002, Bernie Volz (EUD) wrote:
> 
> > Hum, my understanding of -22 is that a client MUST go (back) to the Solicit state to "request" new IAs. Request, Renew, Rebind can only be used on IAs that have been used in a Solicit (or better yet, returned by a server in an Advertise response to a Solicit):
> > 
> > 18.1.1. Creation and transmission of Request messages
> > 
> >    The client uses a Request message to populate IAs with addresses
> >    and obtain other configuration information.  The client includes
> >    one or more IA options in the Request message, with addresses and
> >    information about the IAs that were obtained from the server in a
> >    previous Advertise message.  The server then returns addresses and
> >    other information about the IAs to the client in IA options in a
> >    Reply message.
> 
> So 18.1.1 is correct that the client can later poplulate IAs with
> addresses by sending IA Address Options with an IA with Request.
> 
> > 
> > I'm not necessarily completely happy with this (as I suspect you aren't), 
> >but I think it has some benefits - since it is also possible that if
> >there are multiple servers, some may be configured to provide DSTM
> >addresses and others not?
> >
> 
> We are fine with the current text completely.  I believe you may be
> confusing IAs with IA Address Options.
> 
> In the case of DSTM the server that tells the client they need a DSTM
> address in early deployment of IPv6 will also have the DSTM addresses and
> possibly nothing else for clients.  Its purely a server that knows thru
> user administration that specific clients need DSTM addresses.  Its an
> optimization early on designed in DSTM (go see NGTRANs DSTM discussions
> and presentations) to permit this kind of relationship via dhcpv6.
> 
> But as you suggest is also possible and most likely at medium and long
> term IPv6 deployment where the client is best off going to solicit to find
> the server.
> 
> DHCPv6 -22 supports both mechanisms and our IA and IA Address Options work
> well in both cases and we have done a good job in the working group to
> support this need from NGTRANS in the community.
> 
> regards,
> /jim
> 
>

---

From: Jim Bound <[email-masked]>
Date: Tue, 15 Jan 2002 03:59:24 -0500 (EST)

OK.  thats correct.  I was presenting the logic model for DSTM processing.
thx
/jim

/jim

> > support this need from NGTRANS in the community.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Tue, 15 Jan 2002 20:05:56 +0530

I have gone through the dhcpv6 22 spec.
I felt that, static route option (option 33 in RFC 2132) is missing.
which is useful for routing. Can we include this option
also in the spec? 
thanks and regards
Vijay

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 16 Jan 2002 09:34:30 +0100

Hi Vijay,

why do you think a static route option is needed at all?
For the sake of autoconfiguration it is better to keep the routing 
information in the routers and to provide only a default router to the host 
(which is done through the router advertisements). In the case that the 
router is not the best choice for a specific route, the router will  send 
an ICMP redirect message to the corresponding host, to inform about a 
better router for this route.

Regards
Martin

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Wed, 16 Jan 2002 14:23:30 +0530

Hi Martin,

RFC for autoconf says that, in the absence of router,
the host must use DHCP. In this case, the static
route option will be very much helpful, for configuring 
the routes. 

Regards
Vijay

> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 2:05 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [dhcwg] static route option for dhcpv6
> 
> 
> Hi Vijay,
>

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 16 Jan 2002 11:40:53 +0100

> RFC for autoconf says that, in the absence of router,

That's right.

> route option will be very much helpful, for configuring

In the case of no on-link router, no routes are required!

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Wed, 16 Jan 2002 16:51:02 +0530

> Sent: Wednesday, January 16, 2002 4:11 PM
> Subject: RE: [dhcwg] static route option for dhcpv6
>
>
>
>

In the absence of an on-link IPv6 router, hosts might use configured tunnels
to reach other IPv6 networks. Such routes can be sent in static-route
option.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 16 Jan 2002 13:25:58 +0100

> In the absence of an on-link IPv6 router, hosts might use configured
> tunnels to reach other IPv6 networks. Such routes can be sent in
> static-route option.
>

Yes, this might be useful, but doesn't sound directly like static routes, 
but more than transistioning mechanismen (IPv6 over IPv4 tunnel). There are 
two DSTM options in the draft, but they may not be sufficient for this 
purpose.

Martin

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 16 Jan 2002 09:08:41 -0700 (MST)

> From: Martin Stiemerling <[email-masked]>
> To: [email-masked], [email-masked]

> two DSTM options in the draft, but they may not be sufficient for this 

Doesn't IPv6 have an equivalent to the router discovery protocol?

Vernon Schryver    [email-masked]

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 16 Jan 2002 17:37:10 +0100

> Doesn't IPv6 have an equivalent to the router discovery protocol?

Router discovery via NDP.

Martin

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Wed, 16 Jan 2002 23:46:40 +0530

We can use this for forwarding from the network which 
don't have any router advertisement, but has a node
in the network, attached to the another network and has 
ip-forwarding enabled. 
~vijay

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Martin Stiemerling
> Sent: Wednesday, January 16, 2002 5:56 PM
> Yes, this might be useful, but doesn't sound directly like 
> 
static routes,

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 18 Jan 2002 09:21:34 +0100

Ok, plesse see me prior email.

Martin