Subject: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04

From: Wojciech Dec <[email-masked]>
Date: Thu, 15 Apr 2010 16:02:49 +0200

Hi,

Given that RS triggered access appears to be gaining ground (based on the
latest  draft-krishnan-rs-mark) it would appear that the CPE router draft
specify a bit more tightly the form of RS messages a CPE sends when
connecting to a network.
RFC4861 section 6.3.7 states:
" A host sends Router Solicitations to the all-routers multicast
   address.  The IP source address is set to either one of the
   interface's unicast addresses or the unspecified address."

Now, since the source address is very likely to be one of the identifier
keys for a CPE used for authorization, I would like to propose that an RS
sending rule be added to the CPE spec which would ensure that the IP source
address is NEVER the unspecified address, eg:

The IPv6 CE router MUST use one of its WAN interface unicast addresses when
sending RS messages.

Comments?

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 15 Apr 2010 17:04:32 +0200

>The IPv6 CE router MUST use one of its WAN interface unicast addresses when

Does that mean that if you use your neighbor's mac address, you will get 
your neighbors prefix?

draft-krishnan-6man-rs-mark-03 talks about a LIO option. Which should be
enough to identify the customer.

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 15 Apr 2010 17:26:48 +0200

> Does that mean that if you use your neighbor's mac address, you will get

Well, I meant "MUST use of its WAN interface *IPv6* unicast addresses...

> enough to identify the customer.

The LIO is one key, however the LL and unicast IP addresses of a CE need to
be correlated to that key, hence they are essential pieces of info.

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 15 Apr 2010 18:38:39 +0200

>Well, I meant "MUST use of its WAN interface *IPv6* unicast addresses...

Yes, but on an ethernet, a link local address is often derived from the
mac address.

>be correlated to that key, hence they are essential pieces of info.

Why would the edge router even look at the source address if there is a 
LIO? 

The source address is typically under control of the customer, and cannot be
trusted.

---

From: Fred Baker <[email-masked]>
Date: Thu, 15 Apr 2010 09:47:01 -0700

> Yes, but on an ethernet, a link local address is often derived from the

unless you happen to be using the operating system that sits on 90%+ of desktops: http://ipv6int.net/systems/windows_vista-ipv6.html#privacy is an example of several sites I have found commenting on Windows XP, Vita, and Windows 7. It uses privacy addresses, which are random numbers.

> The source address is typically under control of the customer, and cannot be

http://www.ipinc.net/IPv4.GIF

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 15 Apr 2010 20:02:52 +0200

> Why would the edge router even look at the source address if there is a

It's necessary to know the source address for an LIO in order to at least
associate that IP to the LIO identity.

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 15 Apr 2010 20:30:59 +0200

>associate that IP to the LIO identity.

Which node needs the link local address of the CPE? The edge router or
the access node? (using draft-krishnan-6man-rs-mark-03 terminology)

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 15 Apr 2010 14:05:19 -0500

RFC 4861 says (in section 4.1):

"Source Address
 An IP address assigned to the sending interface, or
 the unspecified address if no address is assigned
 to the sending interface."

I guess you'll always have a link-local address (if not a global unicast
address) on the WAN interface - so other than restricting this more in
the CPE router draft than what RFC 4861 allows, I see no show-stopper
issue with not allowing the unspecified address.  However, I would like
to see more discussion as to why you think this is necessary (ie. are
you denying RA's to "unauthorized" CPE routers?)

- Wes

Wes Beebee
Software Engineer
Product Development
[email-masked]

United States
Cisco.com - http://www.cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
Sent: Thursday, April 15, 2010 10:03 AM
To: [email-masked]
Subject: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04

Hi,

Given that RS triggered access appears to be gaining ground (based on
the latest  draft-krishnan-rs-mark) it would appear that the CPE router
draft specify a bit more tightly the form of RS messages a CPE sends
when connecting to a network.
RFC4861 section 6.3.7 states:
" A host sends Router Solicitations to the all-routers multicast
   address.  The IP source address is set to either one of the
   interface's unicast addresses or the unspecified address."

Now, since the source address is very likely to be one of the identifier
keys for a CPE used for authorization, I would like to propose that an
RS sending rule be added to the CPE spec which would ensure that the IP
source address is NEVER the unspecified address, eg:

The IPv6 CE router MUST use one of its WAN interface unicast addresses
when sending RS messages.

Comments?

-Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 16 Apr 2010 11:49:18 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Philip Homburg
Sent: 15 April 2010 20:31
To: Wojciech Dec (wdec)
Cc: [email-masked]
Subject: Re: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04 

Woj> Likely both: The edge router is expected to have an address binding
table per CPE and so may the access-node.

-Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 16 Apr 2010 11:49:18 +0200

-----Original Message-----
From: Wes Beebee (wbeebee) 
Sent: 15 April 2010 21:05
To: Wojciech Dec (wdec); [email-masked]
Subject: RE: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04

"Source Address

Woj> If one designs a system whereby RAs are used to trigger an
authorization event, it's practically a given that after authorization a
given address (used for sourcing the RSes) is to be bound to that
authorized CPE (it's MAC address). Security proposals are in place (BBF
and SAVI) to have the edge router drop packets which do not have such a
binding. As such it is pretty much critical to have the RSes use a
specific source address.

-Woj.

- Wes

Wes Beebee
Software Engineer
Product Development
[email-masked]

United States

-----Original Message-----

Hi,

Comments?

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 17 Apr 2010 11:53:29 +0200

>table per CPE and so may the access-node.

Maybe I'm missing something. I would expect the edge router to maintain a
mapping from prefix to vlan. It can then use normal neighbor discovery to
find the mac address for a CPE.

The access node is mostly a bridge. But it may have to filter on mac address
(and prohibit direct CPE-to-CPE communication) to increase security a bit.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Apr 2010 15:05:32 +0200

Hi All,

As a follow-up to the discussion, here's some proposed text for the "WAN
side requirements" in Section 4.2:

W-x:    The router MUST orignate RS messages with a source IP address set to
one of the interface's unicast addresses.

Rgds,
Woj.

On 15/04/2010 16:02, "Wojciech Dec" <[email-masked]> wrote:

> specify a bit more tightly the form of RS messages a CPE sends when connecting
> to a network. 
> Now, since the source address is very likely to be one of the identifier keys
> for a CPE used for authorization, I would like to propose that an RS sending
> rule be added to the CPE spec which would ensure that the IP source address is
> NEVER the unspecified address, eg:
>

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Apr 2010 15:01:44 +0200

> find the mac address for a CPE.

That's not what is envisaged in the BBF and SAVI work. The L2-IP binding
would be learned at user authentication time and likely fixed so as to
prevent some rogue user from polluting the binding table.

> (and prohibit direct CPE-to-CPE communication) to increase security a bit.
The main issue is the IP-L2 binding and the ability to establish it when the
user is authenticated. Attempting to patch together such a binding after
authentication is far from being a good thing.

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 26 Apr 2010 15:13:24 +0200

>prevent some rogue user from polluting the binding table.

The MAC address is available as the source ethernet address in the router
solicitation.

How does having a link-local IPv6 address help?

Unless, with L2-IP binding you mean a binding between the link-local address
and the MAC address. But I'm not quite sure why you would need that.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Apr 2010 15:21:09 +0200

> How does having a link-local IPv6 address help?

It helps in being able to bind the MAC to an IPv6 address for that
subscriber. Coincidentally, this is exactly what is already in place for v4.

> and the MAC address. But I'm not quite sure why you would need that.
Without such a binding, LL spoofing becomes an issue.

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 26 Apr 2010 15:33:02 +0200

>subscriber. Coincidentally, this is exactly what is already in place for v4.

Why the link local address? 

>Without such a binding, LL spoofing becomes an issue.

Can you be a bit more specific?

IPv4 doesn't have a link local address.

So what kind of traffic do you expect to and from the link-local address.
There is of course the neighbor discovery stuff. But you probably have to
filter that already to avoid customers talking directly to each other
without going through the router.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Apr 2010 16:06:10 +0200

> Why the link local address?

It can be any unicast address.

> IPv4 doesn't have a link local address.

In IPv4 the binding is DHCP derived, something that is a bit harder to
assume with IPv6.
BTW IPv4 does have LLs too, but they happen not to be commonly used (at
least not by CPEs).

> without going through the router.
For the CPE the vital traffic is DHCP-PD signaling and this will be sourced
from a LL address. If one assumes that an RS is the trigger for user
authorization, securing the address binding at that same time is optimal and
useful in also securing any follow-on DHCP-PD assignment, besides any other
traffic that would suffer from spoofed LLs.
Note that the binding table will need to factor in the other unicast
addresses too.

Do you see any downside of the proposal?

-Woj.
-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 26 Apr 2010 16:28:22 +0200

>It can be any unicast address.

Yes, but in the context of an RS, that will be the link-local address. Or
are you thinking of requiring the use of a global IPv6 address as the
source of RS messages?

>BTW IPv4 does have LLs too, but they happen not to be commonly used (at

Can we stick to what is actually used in the context of CPEs?

I know that IPv4 LL address exist, but I have a hard time understanding how
you would use them to provide a customer with a working Internet connection.

So for IPv4, you need a binding between the global IPv4 address and the MAC
address.

For IPv6 you need to bind IPv6 addresses or prefixes to MAC addresses.

No need for link-local addresses.

>Note that the binding table will need to factor in the other unicast

If you already have a link identifier for the RS, why not use it as well for
the DPCP-PD? 

Are you really assigning DHCP-PD prefixes based on the link-local source
address in the solicit?

>Do you see any downside of the proposal?

I think there is a recent trent to just add all kind of extra requirements
for CPEs that are not there in the underlying protocols.

In my opinion, if you really need this, just get RFC-4861 changed to disallow
the use of an unspecified address as the source of an RS.

But I still have no clear picture how a customer can spoof things using his
link local address.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Apr 2010 16:49:51 +0200

As you can see, whether the global or LL IPv6 address is used is
unspecified. From my perspective the LL is more likely, and is what the BNG
would prefer to see.

> No need for link-local addresses.

LLs are absolutely needed. DHCPv6 uses them as does ND. Furthermore, in the
CPE draft we support the so called "unnumbered" model, whereby the WAN
interface has NO global IPv6 address.

> If you already have a link identifier for the RS, why not use it as well for

I'm referring to creating an IP-L2-binding using an IP address obtained from
an RS, which is used to authorize a customer.

> Are you really assigning DHCP-PD prefixes based on the link-local source

This is not what I said.

> the use of an unspecified address as the source of an RS.

RFC-4861 allows *both*, thus it is something that is supported in the
"unerlying protocols". The unspecified address option in 4861 was/is there
to allow a host to issue an RS  on the WAN interface before attempting or
completing SLAAC. Since in the CPE spec we assume SLAAC (and DHCP-PD), I'm
saying that it would be highly welcome for the CPE to use a tighter form of
the RS sending rule, which will make BNG processing easier.

> But I still have no clear picture how a customer can spoof things using his
The issue is one of overwriting ND cache entries in the BNG, by having one
customer spoof another's LL address.

I take it that other than clarifications, you see no issue with the
proposal.

-Woj.

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Apr 2010 17:45:18 +0200

Woj,

> one of the interface's unicast addresses.

let me see if I understand where you are coming from. this is for an DSL/GPON access network, where you require some isolation between the CPEs. so you don't do address resolution downstream, but you depend on things like DHCP snooping to learn address to L2 address bindings. then to learn the link-local to L2 binding, you obviously need something different than DHCP. so the only reliable protocol you're left with is the RS/RA exchange. correct?

so something like this?

W-x: The IPv6 CE router MUST generate a link-local address and finish Duplicate Address Detection according to RFC4862 prior to sending any Router Solicitations on the interface. The source address used in the subsequent Router Solicitation MUST be the link-local address on the WAN interface.

this is contrary to the section 4 of RFC4862 by the way, which recommends the processes should be done in parallel. BBF's TR-124i2 also has DAD and router solicitation done in serial.

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Apr 2010 19:26:40 +0200

On 26/04/2010 17:45, "Ole Troan" <[email-masked]> wrote:

> let me see if I understand where you are coming from. this is for an DSL/GPON
> access network, where you require some isolation between the CPEs. so you
> don't do address resolution downstream, but you depend on things like DHCP
> snooping to learn address to L2 address bindings. then to learn the link-local
> to L2 binding, you obviously need something different than DHCP. so the only
> reliable protocol you're left with is the RS/RA exchange. correct?

Close...
The broadband access model has come to adopting/relying on RS messages as an
authorization trigger with line-id info (draft-krishnan). Notably RS
messages are the only ones to contain such info.
As such, it's pretty much de-rigueur to be able to bind at authorization a
subscriber to their source IP address and prevent IP spoofing of that
subscriber on a shared access medium. In IPv4 this is sometime known as
ARP-lock, and happens during DHCP authorization.
If the inclusion of a specific IP address in RS messages is left as
unspecified, then effectively no such binding between ip-l2 and line-id is
possible esp given that there is no guarantee of receiving any subsequent RS
(containing line-id + ip address) from that same CPE. As such it becomes
non-trivial to defend the CPE's IP address (identified by the line-id),
especially the LL address, from spoofing.

> 
> so something like this?
> 
> W-x: The IPv6 CE router MUST generate a link-local address and finish
> Duplicate Address Detection according to RFC4862 prior to sending any Router
> Solicitations on the interface. The source address used in the subsequent
> Router Solicitation MUST be the link-local address on the WAN interface.

That's even clearer, great.

> 
> this is contrary to the section 4 of RFC4862 by the way, which recommends the
> processes should be done in parallel. BBF's TR-124i2 also has DAD and router
> solicitation done in serial.

Serial execution of DAD and RS is fine and as such there is no harm to have
the serialized RS use a specific IP address.

-Woj.

>>> connecting
>>> keys

---

From: Philip Homburg <[email-masked]>
Date: Tue, 27 Apr 2010 16:13:29 +0200

>interface has NO global IPv6 address.

What's the point of requiring a RS if there is not going to be prefix anyhow?

If a router is configured for PD, it may just as well leave out the RS
all together.

>an RS, which is used to authorize a customer.

Is there anything special in those RS message (some kind of encryption, HMAC)
that really authorizes the customer, or do you just accept any random 
MAC address and link-local address, allowing any customer to create a 
denial of service attack on another customer?

>customer spoof another's LL address.

How does that help? A customer gets the wrong DHCP reply?

It would be nice if you could describe a specific attack that is allowed by
not binding to the LL addresses early on, and cannot be prevented easily.

>I take it that other than clarifications, you see no issue with the

It is fine with me if you update RFC-4861 for all links and all cases. 
I don't think it is a good idea to create all kinds of different versions of
the neighbor discovery protocols depending not on the link type, but how the
link is used.

If you do ND over ethernet, there should be one set of rules for doing that.
And not one set of rules for ordinary ethernet and another if you happen
to connect to an ISP.

(IMHO the same thing applies to using RA messages as a poor man's routing 
protocol. If that is what is needed, then add some flags or options to
RA, don't just change the meaning of an RA depending on how the link is used).

---

From: Mark Smith <[email-masked]>
Date: Wed, 28 Apr 2010 07:48:18 +0930

On Tue, 27 Apr 2010 16:13:29 +0200

> If a router is configured for PD, it may just as well leave out the RS

Customers in some markets own their CPE. As an ISP, I don't want them
to be able to choose to use LLs only on their link, because that link
is the ISPs to manage and make the choice as to what sort of
addressing they want to use on it (customers can do what they like on
their LAN interfaces - that's their network). Disabling RS when
DHCPv6-PD was enabled would prevent the level of control an ISP needs
to have to provide a good quaility of service (ever tried to
ping/traceroute to a remote LL for troubleshooting purposes? And I
really don't want helpdesk staff constantly logging into edge routers,
even if it was automated and controlled via scripts - they might decide
to have fun and DoS it with many, many script execution attempts)

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 28 Apr 2010 08:47:17 +0200

> And not one set of rules for ordinary ethernet and another if you happen

Updating RFC4861 is not the intent and there is no modification of the
protocol being proposed here. Citing from the begging of this thread:

RFC4861 states:

As such having Rses with a unicast address is already covered by the
protocol. The proposed change tightens the CPE's RS sending rule, which
combined with serialized DAD (or even optimistic DAD), makes sense.

-Woj.

---

From: "Konrad Rosenbaum" <[email-masked]>
Date: Wed, 28 Apr 2010 12:58:24 +0200 (CEST)

Hi,

>From a programmers perspective I do not think that it would be realistic
to tighten this specific requirement and expect people to comply. There
aren't many router vendors out there who write the entire software stack
of their routers - this is especially true for (relatively cheap) CPE
equipment.

The RS/RA and DAD protocols are usually implemented deep inside the
operating system kernel. I can't even find an option for Linux to switch
between RA with LL and null source address.

So in order to make sure I comply with such a requirement I would have to
dig deep into the kernel source and probably change it, while I would
already be under a very tight schedule fighting against my hardware
platform vendors development kit.

Right now is one of the very few moments that I'm happy I don't work for a
CPE router manufacturer. ;-)

On a related note: I would expect ISP side equipment to work with most
common systems out there without forcing significant or unintuitive
changes on them. In this particular case: find a way to inspect the MAC
address or line-ID instead of relying on the LL source address of the RA
message.

    Konrad

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 28 Apr 2010 13:27:28 +0200

> platform vendors development kit.

That is an implementation detail. One can well argue that the CPE spec goes
beyond vanilla router v6 stacks in a number of other areas, eg the handling
of the RA flags. The BBF spec goes into even finer detail, and IMO it would
be a bit naive to have the CPE spec just represent some status quo of v6
implementations; we have a CPE spec so that vendors can build to it CPEs and
other devices (CMTSes, BNGs, etc), and operators have a model reference of
the expected behaviour.
Functionally, as I said previously, it's important for the RS that is used
to authenticate a given user to contain an IP address that can be attributed
to that same user at the BNG. With serialized DAD and RS sending on the CPE,
I really do see it as a logical thing to define.

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 28 Apr 2010 19:33:39 +0200

>combined with serialized DAD (or even optimistic DAD), makes sense.

IMHO, changing RFC-4861 is what is required if you can't live with the
unspecified address (or any global address).

This goes in the direction of OSI-like profiles, something IPv4 seemed have
avoided mostly.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 28 Apr 2010 19:30:32 +0200

>to have fun and DoS it with many, many script execution attempts)

Some ISP do not assign any address to the WAN link and the DHCP-DP RFC prevents
me from assigning a address from the prefix to that link. That annoys me to no
end.

But worse, when every ISP comes up with an arbitrary list of features (and
requirements) it becomes almost impossible to help a random person with his
internet connection.  Oh, you don't have a global IP address on WAN link, is
that normal because the ISP doesn't assign one, or did something go wrong?
Neighbor discovery doesn't work, is that normal because the ISP disabled it,
or is something really broken. You only know if you know the details of 
every ISP.

But more practically speaking, how do you know the global IPv6 address of
your customer? With SLAAC you would have to know the MAC address to even
guess that address. Do you guess it based on the link-local address? Do you
call the customer? What if the customers CPE uses temporary (privacy)
addresses?

If you want that kind of control, why not prohibit customer from using there
own CPEs? Limit official support to just the CPEs supplied by the ISP. There
almost endless list of things random CPEs can do wrong.

With prefix delegation, a router is very likely to have at least one global
address from the delegated prefix.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 28 Apr 2010 19:45:00 +0200

In your letter dated Wed, 28 Apr 2010 13:27:28 +0200 you wrote:
>The BBF spec goes into even finer detail, and IMO it would

We are not talking about random behavior of some implementation. These
are features of the protocols that are explicitly allowed by the standards.

For example, the neighbor discovery RFC could be updated to include that the
host can send RS messages with the unspecified address as long as DAD is
not finished for the link-local address. And that they should send at least
a certain number of RS messages with the link-local address as source
(unless an RA is received before that time).

I think that would help implementators and end-users a lot more than random
requirements in a CPE spec.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 28 Apr 2010 20:00:51 +0200

> unspecified address (or any global address).

Why aren't you also claiming that M and O flag behaviour as specified by
this document requires a change of 4861? That same logic of tightening the
spec to fit a specific type of device applies there too, and arguably is one
of the main values of this draft.

-Woj.

---

From: Ole Troan <[email-masked]>
Date: Wed, 28 Apr 2010 21:47:25 +0200

Philip,

[...]

this no longer appears to concern RSes... but.

> me from assigning a address from the prefix to that link. That annoys me to no

I don't understand what the problem with this is. the CPE draft recommends that an address is configured on an internal interface. why does it matter to which interface the address is on?

> or is something really broken. You only know if you know the details of 

what arbitrary features are those?
there are 3 addressing models. SLAAC, DHCPv6 and "unnumbered".
all models use SLAAC.
ND is used. I'm not aware of anything that requires 'details of every ISP' to understand.

> call the customer? What if the customers CPE uses temporary (privacy)

if you are an SP that requires to know the customers address, then you use DHCPv6 for address assignment.

> address from the delegated prefix.

yes. are you arguing that this address should be well known? since there is no way you can assign that via DHCP. or are you arguing that there should be a mechanism to discover it? e.g by using the subnet-router anycast address?

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 29 Apr 2010 07:16:38 +0930

On Wed, 28 Apr 2010 19:45:00 +0200

> requirements in a CPE spec.

I'm afraid I think it is time to stop considering fiddling with
existing and functional specifications to a achieve micro-efficiencies
such as saving a packet here and there, or saving small amounts of IPv6
address space.

Right now, the priority needs to be on getting IPv6 deployed, which
means accepting things when they are adequate to perform the task,
rather than persisting until they're 'technically perfect' - commonly a
matter of opinion of course, so it may actually never be achieved in
some people's mind.

Regards,
Mark.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 28 Apr 2010 19:21:50 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, April 28, 2010 7:27 AM
To: Konrad Rosenbaum
Cc: Philip Homburg; [email-masked]
Subject: Re: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04

>to that same user at the BNG. 

I totally disagree using the source of the RS to authenticate a user!  I
agree with Konrad who says to use a L2 ID like line id in DSL.  In cable
broadband deployment we use a SID (Service ID of the cable modem).
Using source of a control message to authenticate a user is also very
poor form of authenticating users when one has well defined
authentication mechanisms.  Or if you meant delineate users rather than
authenticate users, then too, the source address of the RS does not make
sense.  One will again ask why the L2 ID of the broadband deployment is
not enough.  It would be good if one comes with a complete document to
the IETF 6man group like how Suresh Krishnan has done to explain his
needs of the DSL network and help define protocol to meet certain goals.
Then we discuss what if any, impact has any deployment on the IPv6 CE
Rtr.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 28 Apr 2010 19:38:20 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
Sent: Monday, April 26, 2010 10:50 AM
To: Philip Homburg
Cc: [email-masked]
Subject: Re: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04 

>customer spoof another's LL address.

Hmm, unless the DSL deployment is explained better in an IETF document
we will thrash forever discussing issues in DSL.  So now I can only
reply based on a guess for what the DSL network may look like.  Why is
the BNG not using some identifier like a line id and not letting another
customer spoof a LL address in the BNG's neighbor cache?  The  DSL
broadband standards should be able to fix such a basic problem.

Hemant

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 29 Apr 2010 09:01:31 +0200

> broadband standards should be able to fix such a basic problem.

There is NOTHING DSL specific about IPv6 address spoofing on a shared access
medium (eg ethernet, docsis, wireless, etc).
In order to use a line-id, there has to be some way of associating the
line-id to an address. If the line-id arrives in an RS message without an IP
address, doing so gets complicated.

-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 29 Apr 2010 09:23:47 +0200

> broadband deployment we use a SID (Service ID of the cable modem).

It appears that you have not followed the discussion (the source address is
to be used to bind the address to a user, not to authenticate), nor read
draft-krishnan-rs-mark or savi activities. I suggest that you do so, incl
the extensive mail archives on those topics, and come back explaining your
technical concerns more clearly.

-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 29 Apr 2010 09:36:42 +0200

> requirements in a CPE spec.

Indeed that may be a nice thing, however I'm sure you appreciate that the
practicalities of changing an rfc are very different from clarifying or
tightening some rfc behavior on a device meant to fulfill a specific role
(eg the CPE). 
The behavior expected with respect to certain RA flags has been discussed
for years, with ambiguous conclusions. As such, it's very pragmatic that the
CPE draft lays down more clarity in some areas, esp. When they have the
potential to make the behavior of the system more deterministic. As such
these requirements are anything but random.

-Woj.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 29 Apr 2010 09:11:51 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
Sent: Thursday, April 29, 2010 3:37 AM
To: Philip Homburg
Cc: [email-masked]
Subject: Re: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04 

>these requirements are anything but random.

I agree with Woj totally on this one.  The IPv6 CE Rtr can tighten text
rather than going back to changing any RFCs.  For example, we could add
text to the IPv6 CE Rtr saying the device sends up to three RS's and
then given up IPv6 address acquisition if no RA is received.  Cable
modems in Docsis 3.0 have such a specification. The IPv6 CE Rtr can also
tighten text to say the RS must include a source address and if source
address is included in the RS, note, one can also include the source
link-layer address option in the RS as well.  However, it is always good
to first understand why a certain deployment cannot do without the RS
being sent with a specified src-address rather than an unspecified
address.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 29 Apr 2010 09:05:53 -0500

-----Original Message-----
From: Wojciech Dec (wdec) 
Sent: Thursday, April 29, 2010 3:24 AM
To: Hemant Singh (shemant); Konrad Rosenbaum
Cc: Philip Homburg; [email-masked]
Subject: Re: RS sending in draft-ietf-v6ops-ipv6-cpe-router-04

>technical concerns more clearly.

I wanted to clarify why the term of authenticate was used as snipped
below from one of the emails on this thread. 

"Functionally, as I said previously, it's important for the RS that is
used to authenticate a given user to contain an IP address that can be
attributed to that same user at the BNG."

Further, I have been following Suresh's documents in 6man and that WG
has not agreed to his documents yet.  It's not like I have not read the
documents.   I have basic fundamental questions like what others (Thomas
Narten for one) in 6man have asked on RA marking - what exactly is the
DSL problem that work of such drafts is needed?  What is there to read
when not a single DSL related document has been accepted as a 6man WG
work item?  As for SAVI activities, it is interesting to me that SAVI
for DSL is being worked on when 6man doesn't even agree upon what is the
DSL IPv6 data problem that needs specification.  I am responding do this
thread for the IPv6 CE Rtr trying to understand what extra reqs need to
go into the CE Rtr document.  The IPv6 CE Rtr document does not want to
include any text for issues in a state of flux.  Why is the RS with
unspecified src address a problem but the NS(DAD) with unspecified src
address not a problem?  Doesn't DSL have to deal with NS(DAD)? Or have
DSL standards dispensed with NS(DAD)?  These are the issues that first
need some clarity in the IETF before one can jump to SAVI or adding reqs
to the IPv6 CE Rtr.  

Hemant

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 29 Apr 2010 16:29:23 +0200

> need some clarity in the IETF before one can jump to SAVI or adding reqs

In terms of DSL specifics: Please re-read my other reply "There is NOTHING
DSL specific about IPv6 address spoofing on a shared access medium (eg
ethernet, docsis, wireless, etc). " RA marking is something that may get
used irrespective of access medium too.

Other than asking for the why's (which would be explained should you follow
my earlier suggestion of understanding both ip address binding concepts
(SAVI) and 6man progress) please clarify what issue do you see with the CPE
requirement for the RS to come out with a specified IP address, which is the
only requirement.
Your reply so far indicates that the only reason for your objection is
non-technical.

-Woj.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 29 Apr 2010 17:19:21 +0200

>of the main values of this draft.

Because in my opinion those flags are for the autoconfiguration of hosts.
And the only must I could find in the draft is that router must do a DHCPv6
request for a prefix.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 29 Apr 2010 17:51:58 +0200

In your letter dated Wed, 28 Apr 2010 21:47:25 +0200 you wrote:
> I don't understand what the problem with this is. the CPE draft
> recommends that an address is configured on an internal interface.
> why does it matter to which interface the address is on?

Because, with picking a global address from a random interface it is mich
harder to ensure the ICMP error gets te source address I want it to have.

And also because the reason for disallowing it is not all that strong.

> what arbitrary features are those? there are 3 addressing models.
> SLAAC, DHCPv6 and "unnumbered".  all models use SLAAC.  ND is used.
> I'm not aware of anything that requires 'details of every ISP' to
> understand.

If you come across a CPE that fails in some unspecified way (somebody asked you
for help because the Internet is down or something like that) how do know
what is normal or not?

Not all CPE have extensive debug interfaces where you dump all packets.

If all links have global IP addresses then you know what is going on if you
find one that doesn't.

I don't know about the 'ND is used' part. But my ISP's router does not respond
to NS messages (on a PPP link). I think they believe that that's allowed by
the standards. Are you saying it isn't?

> yes. are you arguing that this address should be well known? since
> there is no way you can assign that via DHCP. or are you arguing
> that there should be a mechanism to discover it? e.g by using the
> subnet-router anycast address?

If people want to ping routers that get a prefix using PD then that seems to
be a sensible approach.

---

From: Ole Troan <[email-masked]>
Date: Thu, 29 Apr 2010 18:03:08 +0200

Philip,

> harder to ensure the ICMP error gets te source address I want it to have.

who are you?
for a an ICMP message sent by the CPE to some remote destination I can hardly see it matters.

> for help because the Internet is down or something like that) how do know

I would love to be able to tell SPs exactly how they should operate their networks. perhaps luckily for them I can't.

> Not all CPE have extensive debug interfaces where you dump all packets.

I would expect them to be able to show you the contents of received RAs though.

> If all links have global IP addresses then you know what is going on if you

but that's not quite what you are advocating. an address from the delegated prefix is may be configured on the interface, but the prefix certainly wouldn't be on-link.

> the standards. Are you saying it isn't?

no. e.g NUD should be supported on any link, including PPP links.

> If people want to ping routers that get a prefix using PD then that seems to

I suppose we are digressing here... my apologies.

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 29 Apr 2010 19:46:15 +0200

In your letter dated Thu, 29 Apr 2010 18:03:08 +0200 you wrote:
> I would love to be able to tell SPs exactly how they should operate
> their networks. perhaps luckily for them I can't.

I think to some extent we are doing that. By setting standards.

> I would expect them to be able to show you the contents of received

Sure? I never seen any of the low-end CPE device show the contents of a DHCP
or the PPP options that are negotiated. 

In a (be it experimental release) of a CPE with IPv6 stack you can't
figure out what DUID the device is using. 

> but that's not quite what you are advocating. an address from the
> delegated prefix is may be configured on the interface, but the
> prefix certainly wouldn't be on-link.

That's two separate issues. One is that I'd like to be able to assign a
subset of my prefix to the WAN link. The second issue is that ISPs seem to
create an almost endless variety of different way in which they implement
IPv6.

> no. e.g NUD should be supported on any link, including PPP links.

I'll ask them. 

I think this an area where it may make sense to have some explicit text in
the CPE draft. Because even though by disabling ND my ISP seems to have broken
NUD, none the users ever discovered this or reported a problem. So it looks
as if every PPP implementation just assumes that there is no ND.

---

From: james woodyatt <[email-masked]>
Date: Thu, 29 Apr 2010 12:00:43 -0600

everyone--

I don't understand the logic here.

In the kind of network described in I-D.6man-krishnan-rs-mark-04, when a CPE node sends a router solicitation from the unspecified source address, the AN need not forward it to other attached CPE.  It only needs to be forwarded through the LIO tunnel to the edge router.  When the edge router receives this router solicitation, it responds with a router advertisement to the all-hosts multicast address, which I-D.6man-krishnan-rs-mark-04 says MUST be sent back to the AN through the LIO option tunnel.  The AN then decapsulates the advertisement and sends it back to the originating CPE only because it has the line identifier.

I see no problem here that requires tighter language in I-D.ietf-v6ops-cpe-router than appears in RFC 4861.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 May 2010 01:54:27 +0930

On Thu, 29 Apr 2010 09:11:51 -0500
"Hemant Singh (shemant)" <[email-masked]> wrote:

> modems in Docsis 3.0 have such a specification.

I never think DOCSIS should ever be used as an example of how to do
something properly. They made the fundamental mistake of making a layer
2 technology layer 3 aware. If only they'd kept to the layer they are
supposed to be operating at (i.e. layer 2), then they wouldn't have to
be rolling out DOCSIS v3 to support IPv6, at a very great expense to
themselves and, ultimately, their customers.

If that argument isn't clear, realise that everybody else in the
Ethernet/ADSL/frame relay/ATM/Token Ring/ArcNet/PPP/HDLC/SDLC world
isn't having to roll out a new revision of their layer 2 technology
just to support a new layer 3 protocol.

 The IPv6 CE Rtr can also