Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 11 Feb 2014 21:56:00 +0000

This document did pass the WGLC but we had been waiting for the v4configuration draft, which has passed.

I believe (though need to confirm with the authors) that the 04 draft they published on Jan 17, 2014 incorporates all of the comments from the last call.

We will shortly send this off to advance (we expect to send this and the v4configuration draft about the same time).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, January 14, 2014 4:26 PM
To: [email-masked]
Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03

Hi:

We've left this WGLC open pending the last call on the v4configuration draft. The authors of the v4configuration draft have been working on updating it and should be submitting it shortly, at which time we will start the WGLC for it. We will then close the last calls for both documents (dhcpv4-over-dhcpv6 and v4configuration) at the same time.

Sorry for the delay but as the two documents are closely related, we feel it is best to hold off until both can be reviewed.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Monday, December 16, 2013 9:58 AM
To: [email-masked]
Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

On 16.12.2013 15:40, Simon Perreault wrote:
> Le 2013-12-14 10:10, Bernie Volz (volz) a écrit :
>> WGLC on the related draft-ietf-dhc-v4configuration-03 is in progress
> 
> Is this true? I can't find the announcement, and the datatracker 
> doesn't show the draft as being in WGLC...
No, that was a mistake. Bernie and I exchanged preliminary WGLC announcement text, but due to the discussion about dhcpv4-over-dhcpv6 we still haven't sent it out. So no - there is no WGLC on v4configuration yet, but there likely will be in the next couple days.
It will be long enough so people who take holiday + new year vacation will be able to get back and post their comments when they get back in January.

Tomek

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

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 13 Feb 2014 20:53:07 +0100

Hi,

on re-reading the draft I have one question, perhaps obvious to the
authors, about a technical point that deserves to be clarified: What
is the expected behaviour for the DHCPv4/DHCPv6 server in terms of
selecting the IPv4 address scope? RFC 2131 gives the following SHOULD:

"A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0)."

This draft doesn't mention anything about giaddr, so it's rather
ambivalent whether the relay agent inserts any giaddr and what is the
SHOULD behaviour of the server, etc.

Thanks,
Wojciech.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Feb 2014 20:06:56 +0000

As I see it there are two basic ways to handle this:

1. If the server is a 'special' 4o6 server which handles these DHCPv4 packets directly, it would use the IPv6 source address or Relay-Forw link-address as a lookup to map to a v4 subnet to use. This is similar to how a v4 server uses the interface on which giaddr=0.0.0.0 packets are received.

2. If the 4o6 server will forward this to a normal DHCPv4 server, it would act as a relay and add a giaddr (to get back the packet) and option 82, using the link-selection option-82 suboption to supply the v4 subnet information similar to the processing in (1). Likely the circuit-id or remote-id suboption (or other option-82 suboption) would be used to store enough to be used when the response is DHCPv4 received (minus the giaddr/option-82 information) to get the DHCPv6 packet back to the client. Note that this additional information may just be some kind of hash to the 'saved' state to return the packet to the client.

(It is also possible to use variants of 1 and 2.)

- Bernie

-----Original Message-----
From: Wojciech Dec [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 2:53 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Results of WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03

Hi,

on re-reading the draft I have one question, perhaps obvious to the authors, about a technical point that deserves to be clarified: What is the expected behaviour for the DHCPv4/DHCPv6 server in terms of selecting the IPv4 address scope? RFC 2131 gives the following SHOULD:

This draft doesn't mention anything about giaddr, so it's rather ambivalent whether the relay agent inserts any giaddr and what is the SHOULD behaviour of the server, etc.

Thanks,
Wojciech.

On 11 February 2014 22:56, Bernie Volz (volz) <[email-masked]> wrote:
> Subject: Re: [dhcwg] Results of WGLC for 
> draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013
>