Subject: [dhcwg] Unnecessary restriction in DHCP-PD?

From: Suresh Krishnan <[email-masked]>
Date: Fri, 17 Oct 2008 18:16:03 -0400

Hi Folks,
   I would like to understand the reasoning behind this restriction in 
section 12.1 of RFC3633.

    " the requesting router MUST NOT assign any delegated prefixes or
    subnets from the delegated prefix(es) to the link through which it
    received the DHCP message from the delegating router."

If I get a /56 and use a /64 out of this on the same interface on which 
I received the PD, I do not see anything breaking on either the DR or 
the RR. I would appreciate it if anyone can clarify this.

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Oct 2008 18:23:31 -0400

Ole has already given a reason for this restriction in v6ops as follows:

[let me see if I can recall the arguments at the time:

- the model of prefix delegation in 3633 is strictly hierarchical and
you delegate a prefix typically across an administrative boundary
  the upstream link (link between RR and DR) is managed by the DR
- there are already two mechanisms for address assignment, PD is for
prefix delegation not address assignment. if the delegated prefix
  was subnetted also on the upstream, would the RR send RA's for
example?
- the DR will consider the prefix off-link and not use ND for address
resolution, while the RR thinks the prefix is on-link.]

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Suresh Krishnan
Sent: Friday, October 17, 2008 6:16 PM
To: DHC WG
Subject: [dhcwg] Unnecessary restriction in DHCP-PD?

Hi Folks,

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 17 Oct 2008 18:36:12 -0400

Hi Hemant,
   I read Ole's mail on v6ops as well, but I still do not see the 
technical problem. I am running this setup currently and I am not seeing 
any issues. To narrow down my question, "what exactly breaks when we do 
this?"

Thanks
Suresh

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 17 Oct 2008 16:34:01 -0700

On Fri, Oct 17, 2008 at 06:36:12PM -0400, Suresh Krishnan wrote:
>   I read Ole's mail on v6ops as well, but I still do not see the technical 
> problem. I am running this setup currently and I am not seeing any issues. 
> To narrow down my question, "what exactly breaks when we do this?"

It is an administrative question, not so much a technical one.

The PD client is a client, not representing the network administrator,
on the upstream-facing interface.  It is inappropriate to make changes
to the network's management.  If the network wished to give the client
additional addresses on that segment, the RA PIOs and/or IA_NA would
already reflect that.

Having a delegated prefix does not grant the right to manage the
upstream's network.

Note however that if the PD client was operating as a DHCPv6 server on
its upstream facing interface as well as advertising the delegated
prefixes there, a recursion error would be present; a client on the
upstream side may acheive a prefix delegation from a PD client on the
same link, which in turn is a client of the upstream network, and so
on.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 17 Oct 2008 17:06:56 -0700

At Fri, 17 Oct 2008 18:36:12 -0400,

> any issues. To narrow down my question, "what exactly breaks when we do 

I've heard a subtle technical issue where this restriction of RFC3633
matters (although I doubt it was considered when the spec was
written).  It's related to the recent "clarification" on the
definition of "on-link".

Consider the network where RR and DR are directly connected, and DR
assigns 2001:db8:1234::/48 to the RR.  If the restriction of RFC3633
doesn't exist, the RR may configure its up-link interface (toward the
DR) with, say, 2001:db8:1234::abcd and assume 2001:db8:1234::/64 is
an on-link prefix for the link shared with the DR:

            ::abcd   2001:db8:1234::/64
  --------RR-----------------------------------DR---(ISP network)
(customer
  network)

Now assume the RR sends a packet to an off-link address, e.g,
2001:db8:ffff::5678.  The source address of the packet would be
2001:db8:1234::abcd because the destination is off-link and this
address is the only global address assigned on the outgoing interface
(so RFC3484 would prefer this address).  The RR then performs ND to
resolve DR's link-layer address.  This process is triggered by the
packet whose source address is 2001:db8:1234::abcd, so the source
address of the NS would also have this address per the recommendation
of RFC4861.

Then the DR will receive an NS whose source address is
2001:db8:1234::abcd.  But since it has no knowledge about how the RR
('s site) uses the delegated /48 prefix, it doesn't assume
2001:db8:1234::/64 is on-link.  If we remove the following bullet of
the on-link definition of RFC4861 as we've discussed in the 6man list:

                    - a Neighbor Advertisement message is received for
                      the (target) address, or

the DR won't regard the NS's source address as a neighbor.

What happens next may depend on implementation details, but it would
be tricky (if not impossible) for the DR to return a proper NA in
response to the NS in this situation.  If the DR fails to respond to
the NS, the RR won't be able to send out the triggering packet.

RFC3633's restriction (though probably unintentionally) precludes such
a weird scenario from happening.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 18 Oct 2008 06:02:10 -0400

Suresh,

Ole already said "the DR will consider the prefix off-link and not use
ND for address resolution, while the RR thinks the prefix in on-link".
As we have also said in our IPv6 Subnet Model draft discussions over the
past year, if on vs off-link is wrongly concluded by a node, data
forwarding can break down if the node does not receive any NA reply to
an NS the node issues.  Jinmei also alluded to this fact in his example.

There are other issues.  

(a) The DR will send an RA to the RR who will configure an IPv6 address
on the RR's up-link using DHCPv6 or SLAAC.  What you are doing is manual
configuration that usually puts most IPV6 ND discussions out of scope. 

(b) If the DR and RR are directly connected, they share the same subnet.
One does not connect two routers with disparate subnets on directly
connected routes. 

Also, when you say "you don't see anything breaking" what all did you
test?  Just clear the ND-cache on the RR up-link and issue a ping from
the RR to the DR IPv6 address and in Jinmei's example.  This ping should
fail because the RR will first send an NS to resolve the destination and
this NS should not be responded to because the DR thinks the target of
NS is off-link.  The ping request just stays there at the RR.  Also
remember, if the RR is directly connected to the DR, the RR has
performed NS DAD for link-local address with the DR.  The DR may also
send an off-link Redirect with the Target of the Redirect as link-local
of the RR.  You see how convoluted is this getting.

Hemant

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Friday, October 17, 2008 6:36 PM
To: Hemant Singh (shemant)
Cc: DHC WG
Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD?

Hi Hemant,

Thanks
Suresh

> If I get a /56 and use a /64 out of this on the same interface on 
> which I received the PD, I do not see anything breaking on either the 
> DR or the RR. I would appreciate it if anyone can clarify this.
> 
> Cheers
> Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 18 Oct 2008 06:03:01 -0400

Actually Jinmei, the bullet you want to quote is this one:

- any Neighbor Discovery message is received from
  the address. 

It's not the NA one you have quoted below.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 17, 2008 8:07 PM
To: Suresh Krishnan
Cc: Hemant Singh (shemant); DHC WG
Subject: Re: [dhcwg] Unnecessary restriction in DHCP-PD?

At Fri, 17 Oct 2008 18:36:12 -0400,
Suresh Krishnan <[email-masked]> wrote:

> technical problem. I am running this setup currently and I am not 
> seeing any issues. To narrow down my question, "what exactly breaks 
> when we do this?"

I've heard a subtle technical issue where this restriction of RFC3633
matters (although I doubt it was considered when the spec was written).
It's related to the recent "clarification" on the definition of
"on-link".

Consider the network where RR and DR are directly connected, and DR
assigns 2001:db8:1234::/48 to the RR.  If the restriction of RFC3633
doesn't exist, the RR may configure its up-link interface (toward the
DR) with, say, 2001:db8:1234::abcd and assume 2001:db8:1234::/64 is an
on-link prefix for the link shared with the DR:

Now assume the RR sends a packet to an off-link address, e.g,
2001:db8:ffff::5678.  The source address of the packet would be
2001:db8:1234::abcd because the destination is off-link and this address
is the only global address assigned on the outgoing interface (so
RFC3484 would prefer this address).  The RR then performs ND to resolve
DR's link-layer address.  This process is triggered by the packet whose
source address is 2001:db8:1234::abcd, so the source address of the NS
would also have this address per the recommendation of RFC4861.

Then the DR will receive an NS whose source address is
2001:db8:1234::abcd.  But since it has no knowledge about how the RR ('s
site) uses the delegated /48 prefix, it doesn't assume
2001:db8:1234::/64 is on-link.  If we remove the following bullet of the
on-link definition of RFC4861 as we've discussed in the 6man list:

What happens next may depend on implementation details, but it would be
tricky (if not impossible) for the DR to return a proper NA in response
to the NS in this situation.  If the DR fails to respond to the NS, the
RR won't be able to send out the triggering packet.

RFC3633's restriction (though probably unintentionally) precludes such a
weird scenario from happening.

---
JINMEI, Tatuya

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Oct 2008 10:56:18 -0400

Hi Tatuya,
   Thanks for your comments.

> an on-link prefix for the link shared with the DR:

Our implementation does not make this assumption (that the /64 is 
on-link). It forwards all off-link packets to the default router (which 
is the DR). And similarly the DR forwards all packets destined to the 
/48 to the RR.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Oct 2008 11:44:55 -0400

Hi Hemant,
   Thanks for your comments. Please see response inline.

> NS is off-link.  The ping request just stays there at the RR.  Also

As I said in my mail to Jinmei, our implementation does not 
automatically consider the /64 of a configured address to be on-link. I 
do see your point (and Jinmei's) that there are implementations that do so.

Thanks
Suresh

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 22 Oct 2008 09:31:18 -0700

At Wed, 22 Oct 2008 10:56:18 -0400,

> is the DR). And similarly the DR forwards all packets destined to the 

You miss my point.  I didn't care about what your implementation
does.  I pointed out that what could happen for *some* implementation
if the RFC3633 restriction didn't exist.

---
JINMEI, Tatuya

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 22 Oct 2008 09:33:07 -0700

On Wed, Oct 22, 2008 at 11:41:50AM -0400, Suresh Krishnan wrote:
> This was not my intent (to re-advertize the prefix upstream) but to just 
> use a configured address. I realize now that pursuing this might be more 
> trouble than it is worth. I am probably better off getting a DHCPv6 address 
> or a SLAAC configured address on the upstream interface.

Precisely.  You can probably get a DHCPv6 address in an IA_NA in the
very same packet which allocates your IA_PD, or of course SLAAC.  This
is simpler and more consistent than special-case address models with
PD contents.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Oct 2008 13:06:26 -0400

Hi Tatuya,

> if the RFC3633 restriction didn't exist.

I did realize that, but *such* implementations should not lead to 
restrictions in our specifications. But I have realized that the 
probability of running into one is high enough for this to be justified. 
Thanks again for your clarification.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Oct 2008 11:41:50 -0400

Hi David,
   Thanks for your comments. Please find responses inline.

> It is an administrative question, not so much a technical one.

Ack. I think this might be a good explanation for this restriction.

This was not my intent (to re-advertize the prefix upstream) but to just 
use a configured address. I realize now that pursuing this might be more 
trouble than it is worth. I am probably better off getting a DHCPv6 
address or a SLAAC configured address on the upstream interface.

Thanks
Suresh