Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

Hi:

> What is the Hop Limit that a Solicit should contain in the IPv6 header?

ND uses hop limit of 255 so the destination can check that it is 255 on receipt (whereas 1 could have been anything and forwarded many times).

But I'm not sure if that is a the best practice when you don't want the packet forwarded. I would think that if the destination is a link-local multicast, it really doesn't matter as nothing should forward the packet (and if something is misconfigured to forward the packet, you're probably in deeper trouble than just with DHCPv6).

RFC 4861 has:

11.2.  Securing Neighbor Discovery Messages

   The protocol reduces the exposure to the above threats in the absence
   of authentication by ignoring ND packets received from off-link
   senders.  The Hop Limit field of all received packets is verified to
   contain 255, the maximum legal value.  Because routers decrement the
   Hop Limit on all packets they forward, received packets containing a
   Hop Limit of 255 must have originated from a neighbor.

I don't know off hand if there's any place this is documented (what to use for hop limit with link-local).

> Is IA_NA with empty fields a valid option in a Prefix Delegation Solicit, or must IA_NA be absent altogether? (the intention is to only request the Prefix, because the address comes from RA).

Not sure what an "empty" IA_NA is. Whether you include an IA_NA or not with IA_PD is the client's choice. If it what's an address (such as for management) on the upstream link, than it should include an IA_NA. This is covered in the text in 6.3 (IA_PD only) vs 6.4 (IA_PD and IA_NA, typically).

> Is ORO with empty fields illegal in a Prefix Delegation Solicit?  (the intention is to get the DNS server from RA, but some client puts an empty ORO there).

An empty ORO is fine (it should not cause problems, but is obviously useless). Though if they are following the rfc3315bis and doing what they should, there would not be an empty ORO.

> Is it ok to use a GUA in the src address of a Solicit Prefix Delegation?

See 13.1 of draft-ietf-dhc-rfc3315bis-09 ... the source address here should be link-local. I'd also think using a GLA source address with a link-local destination (multicast) would be rather odd. The 1st "-", third "*" would indicate that this means server-address option has been previously sent which is of course not possible for a Solicit.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Wednesday, July 05, 2017 12:22 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation

What is the Hop Limit that a Solicit should contain in the IPv6 header?

(The ISC and a Cisco client set it at 255, whereas odhcp6c client at 1.
  The dst address is a ff02.
  The ND link messaging uses Hop Limit 255.)

Is IA_NA with empty fields a valid option in a Prefix Delegation Solicit, or must IA_NA be absent altogether? (the intention is to only request the Prefix, because the address comes from RA).

Is ORO with empty fields illegal in a Prefix Delegation Solicit?  (the intention is to get the DNS server from RA, but some client puts an empty ORO there).

Is it ok to use a GUA in the src address of a Solicit Prefix Delegation?
  Is the GUA mandatory, or could LL do it as well? (some server seems to require it to be a GUA).

Alex

Le 29/06/2017 à 02:30, internet-drafts@ietf.org a écrit :
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. This draft is a work item of the Dynamic Host 
> Configuration of the IETF.
> 
> Title           : Dynamic Host Configuration Protocol for IPv6
> (DHCPv6) bis Authors         : Tomek Mrugalski Marcin Siodelski 
> Bernie Volz Andrew Yourtchenko Michael C. Richardson Sheng Jiang Ted
> Lemon Timothy Winters Filename        :
> draft-ietf-dhc-rfc3315bis-09.txt Pages           : 140 Date
> : 2017-06-28
> 
> Abstract: This document describes the Dynamic Host Configuration 
> Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring 
> nodes with network configuration parameters, IP addresses, and 
> prefixes. Parameters can be provided statelessly, or in combination 
> with stateful assignment of one or more IPv6 addresses and/or IPv6 
> prefixes.  DHCPv6 can operate either in place of or in addition to 
> stateless address autoconfiguration (SLAAC).
> 
> This document updates the text from RFC3315, the original DHCPv6 
> specification, and incorporates prefix delegation (RFC3633), stateless 
> DHCPv6 (RFC3736), an option to specify an upper bound for how long a 
> client should wait before refreshing information (RFC4242), a 
> mechanism for throttling DHCPv6 clients when DHCPv6 service is not 
> available (RFC7083), and clarifies the interactions between modes of 
> operation (RFC7550).  As such, this document obsoletes RFC3315, 
> RFC3633, RFC3736, RFC4242, RFC7083, and RFC7550.
> 
> 
> The IETF datatracker status page for this draft is: 
> https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/
> 
> There are also htmlized versions available at: 
> https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-09
> https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc3315bis-09
> 
> A diff from the previous version is available at: 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-rfc3315bis-09
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at: 
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________ dhcwg mailing list 
> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg