Subject: [dhcwg] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01

From: joel jaeggli <[email-masked]>
Date: Tue, 13 Nov 2012 22:49:30 -0800

I took a look at this draft since it was also presented in v6ops...

http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01

There's a couple issues that are quite striking. I kind of concur with 
Fred  Baker that the most appropiate method for tracking l2/l3 binding 
for address identification is probably more akin to syslog.

That is, since you don't really trust the hosts, having a switch/router, 
simply sysloging all new NDP cache entries pretty much achives the same 
thing execept with a lot less signaling.

If a strong assertion of L2 identity in support of l2/l3 bindings is 
required 802.1x or the wireless equivalanet seems appropiate, e.g. it's 
what we do today.

Availing oneself of a dhcp/ra option entails a lot of signaling for what 
is likely a relatively ephemeral port (windows machines and macs 
registering privacy addresses for example). specifiying a binding 
lifetime seems of limited utility since the host will probably discard 
the address long before the lifetime expires if it's sufficently long 
enough to allow for long lived connections using that address.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 16 Nov 2012 00:51:16 +0000

>thing execept with a lot less signaling.

Hi, Joel,

I am not agree the precondition you have here: "since you don't really trust the hosts". The assume we take is that hosts, at least host IP stack, would do this right. Or at least they will do right things by standard definitions. In reality, malicious hosts do not follow the RFCs. Therefore, they are considered as security issues. It only means more security mechanism/infrastructure should be deployed. It should not deny the meaning of address registration. It servers most of ordinary hosts, which may be 99% of all users.

Best regards,

Sheng

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

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 16 Nov 2012 00:56:21 +0000

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of joel jaeggli
>Sent: Wednesday, November 14, 2012 2:50 PM
>To: [email-masked]; IPv6 Ops WG;
>[email-masked]
>Subject: [v6ops] some feedback on

---

From: joel jaeggli <[email-masked]>
Date: Thu, 15 Nov 2012 17:51:27 -0800

On 11/15/12 4:51 PM, Sheng Jiang wrote:
> I am not agree the precondition you have here: "since you don't really trust the hosts". The assume we take is that hosts, at least host IP stack, would do this right. Or at least they will do right things by standard definitions.
That's an interesting assumption given that all pre-existing host stacks 
will be unaware of the availability of the mechanism and therefore not 
use it.
>   In reality, malicious hosts do not follow the RFCs.
untrustworthy hosts aren't necessarily malicious.
>   Therefore, they are considered as security issues. It only means more security mechanism/infrastructure should be deployed. It should not deny the meaning of address registration. It servers most of ordinary hosts, which may be 99% of all users.
I can with relatively minor effort on the part of a vendor capture the 
same information, with a lot less signaling out of the NDP cache on my 
routers, and do so without consideration of hosts behavior.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 16 Nov 2012 02:33:49 +0000

>From: joel jaeggli [mailto:[email-masked]]
>Sent: Friday, November 16, 2012 9:51 AM
>To: Sheng Jiang
>Cc: [email-masked]; IPv6 Ops WG;
>[email-masked]
>Subject: Re: [v6ops] some feedback on
>> I am not agree the precondition you have here: "since you don't really trust
>the hosts". The assume we take is that hosts, at least host IP stack, would do
>this right. Or at least they will do right things by standard definitions.

This argument seems too wide. If so, our IETF should never define any new extension headers/options/mechanisms because all pre-existing host stacks do not unaware them.

For me, your argument is available if it comes like this way: there should be more considerations for how to support backwards compatibility. We can work on that.

>untrustworthy hosts aren't necessarily malicious.

Ok. Let's discuss which part you don't trust from hosts. There are several possibilities I can think out: a) hosts refuse to register their addresses, b) hosts register wrong address/mac on purpose c) host stacks does not register address/mac right. For me, a has been described in the draft; b should be consider as malicious behavior; c is down to implementation, it is not a standard issue.

If you have other untrustworthy considerations, please give details. I am happy to discuss them.

>>   Therefore, they are considered as security issues. It only means more
>security mechanism/infrastructure should be deployed. It should not deny the
>meaning of address registration. It servers most of ordinary hosts, which may
>be 99% of all users.

I agree with you if we only discuss the scenario that first-hop router is fully under management by ISPs. But there are other scenarios, in which first-hop router is home gateway, mobile node and others. For these scenarios, ISP cannot get the address information unless host registering.

Another point is this new registration is bi-direction interaction. It gives ISPs a chance to manage these host-generated addresses, such as denying certain address (such as low sec-value CGA), etc. For now, ISPs has to accept all host-generated addresses. If ISP denies access because of any address-relevant reasons, there is no mechanism to tell hosts why and how to fix it.

Best regards,

Sheng

---

From: joel jaeggli <[email-masked]>
Date: Thu, 15 Nov 2012 20:05:34 -0800

> This argument seems too wide. If so, our IETF should never define any new extension headers/options/mechanisms because all pre-existing host stacks do not unaware them.
There should be a pretty high standard associated with  changing the 
behavior of things which already exist.
> Ok. Let's discuss which part you don't trust from hosts. There are several possibilities I can think out: a) hosts refuse to register their addresses, b) hosts register wrong address/mac on purpose
What is wrong MAC in this case? MACs are generally but not always stable 
(vrrp6 is a pretty good case for not stable), in any event they are 
reconfigurable. A MAC is a layer 2 binding and if you have a strong 
layer-2 authentication (as some centrally managed networks do) then 
forgery is essentially irrelvant. beyond that the correctness of a MAC 
absent ACLs, is limited to it's presence in the bridge table and any 
l2/l3 bindings it may have.
> c) host stacks does not register address/mac right. For me, a has been described in the draft; b should be consider as malicious behavior; c is down to implementation, it is not a standard issue.
>
Either the network is centrally managed or it isn't. The draft describes 
a management entity (enterprise) which is fully in control of the first 
hop router(s). Here you're describing a transitory trust model where my 
first hop router managed by me passes a registration option to my hosts 
to register addresses used on my network with my ISP. That's not, in 
your document.

The network in my house, or my enterprise is managed by me, my ISP once 
they've assigned or delegated a prefix doesn't get to determine if I can 
use an address or not. It is no business of my ISP, if my fridge, or 
thermostat decides to use SLAAC to assign an address from the prefix 
which it plans to use becuase it's covered by RA.
> Another point is this new registration is bi-direction interaction. It gives ISPs a chance to manage these host-generated addresses, such as denying certain address (such as low sec-value CGA), etc…
Interesting use case. It's not in the document however, which you do 
have is.

    After receiving this address registration request, the address
    registration server MUST register the requested address in its
    address database, which may further be used by other network
    functions, such as DNS, network access control lists, etc.

so presumably you tell the IA that it can't have an address by  setting preferred-lifetime and valid-lifetime fields to 0, that doens't seem like an extremely useful message to send back out a client trying to register an address.

Fundamentally if you don't control the network you shouldn't be managing 
address selection on it since you don't know what people will attach. if 
you do then by all means do so.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 16 Nov 2012 06:11:45 +0000

>> Ok. Let's discuss which part you don't trust from hosts. There are several
>>possibilities I can think out: a) hosts refuse to register their addresses, b) hosts
>>register wrong address/mac on purpose

>What is wrong MAC in this case? 

I referred to these malicious hosts, who uses faked MAC to get network access or plays to be other hosts.

>MACs are generally but not always stable

Then, why hosts are untrustworthy to register address?

>> I agree with you if we only discuss the scenario that first-hop router is fully
>>under management by ISPs. But there are other scenarios, in which first-hop
>>router is home gateway, mobile node and others. For these scenarios, ISP
>>cannot get the address information unless host registering.

>to register addresses used on my network with my ISP. That's not, in

Yes, it was not in the document. Since this document is a DHC draft, we focused on the DHCP Protocol interaction and option definition. We did not do very well to describe suitable scenarios until recently. We will work on that. Thanks to help us improve the document.

>> Another point is this new registration is bi-direction interaction. It gives ISPs
>>a chance to manage these host-generated addresses, such as denying certain
>>address (such as low sec-value CGA), etc. For now, ISPs has to accept all
>>host-generated addresses. If ISP denies access because of any
>>address-relevant reasons, there is no mechanism to tell hosts why and how to
>>fix it.

>so presumably you tell the IA that it can't have an address by setting
>preferred-lifetime and valid-lifetime fields to 0, that doens't seem like an
>extremely useful message to send back out a client trying to register an
>address.

Agree, more information should be provided in the case of reject address. Actually, the specific case of denying CGA with low sec-value was solved by another dedicated draft (http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6) , in which a new DHCPv6 option has been defined to feedback a recommended Sec value.

We will improve this part in next update.

Best regards,

Sheng

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 16 Nov 2012 10:36:52 +0100

On 16/11/12 5:05, joel jaeggli wrote:
> On 11/15/12 6:33 PM, Sheng Jiang wrote: I agree with you if we only
> discuss the scenario that first-hop router is fully under management
> by ISPs. But there are other scenarios, in which first-hop router is
> home gateway, mobile node and others. For these scenarios, ISP cannot
> get the address information unless host registering.
> Either the network is centrally managed or it isn't. The draft
> describes a management entity (enterprise) which is fully in control
> of the first hop router(s). Here you're describing a transitory trust
> model where my first hop router managed by me passes a registration
> option to my hosts to register addresses used on my network with my
> ISP. That's not, in your document.
>
> The network in my house, or my enterprise is managed by me, my ISP
> once they've assigned or delegated a prefix doesn't get to determine
> if I can use an address or not. It is no business of my ISP, if my
> fridge, or thermostat decides to use SLAAC to assign an address from
> the prefix which it plans to use becuase it's covered by RA.
I believe this is a very important issue. I have been following this
list for some time now but have not had the time to really read all the
drafts, so please allow me to take a more high level look.

My understanding from most of the discussions have been that a
monolithic network management style has been in the minds of the
writers, however as IPv6 will be deployed generally the management must
have a kind of division point as mentioned above. The ISP delegates the
prefix but all management of this, including registration of hosts into
DNS must be controlled locally. I.e. company XYZ using ISP ABC should be
able to have all their hosts registered as xx.XYZ.tld, not as
xx.ABC.tld. Specially no issue should arise from switching ISP, only the
prefix should change, DNS might be hosted someplace else, maybe at the
head office.

This leads to my question: is this setup taken into account presently?
Is there a clear cut in the system allowing for this division.  I should
be able to read this myself but time has not allowed for that and I have
not seen this in the discussions.
>> Another point is this new registration is bi-direction interaction.
>> It gives ISPs a chance to manage these host-generated addresses, such
>> as denying certain address (such as low sec-value CGA), etc. For now,
>> ISPs has to accept all host-generated addresses. If ISP denies access
>> because of any address-relevant reasons, there is no mechanism to
>> tell hosts why and how to fix it.
> so presumably you tell the IA that it can't have an address by 
> setting preferred-lifetime and valid-lifetime fields to 0, that
> doens't seem like an extremely useful message to send back out a
> client trying to register an address.
>
>
> Fundamentally if you don't control the network you shouldn't be
> managing address selection on it since you don't know what people will
> attach. if you do then by all means do so.
>
>
>> Best regards,
>>
>> Sheng
>>
>>>> Best regards,
>>>>
>>>> Sheng
>>>>
> dhcwg mailing list
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2012 13:40:52 +0000

On Nov 16, 2012, at 1:31 AM, Mark Smith <[email-masked]> wrote:
> I agree with Joel, I think observation by most likely a router is a better method, as it will capture address information regardless of whether it was configured via static, SLAAC or DHCPv6 (or any future methods).

It's certainly true that a router can capture all the IPv4 and IPv6 addresses that a device with a particular MAC address uses.   However, what a router _can't_ do, and what this option allows to be done, is for a device that has autoconfigured to then provide the network administrator with a hint as to what its FQDN should be.   This information isn't available to the router.

It seems to me that although it is true that it is worthwhile to define a mechanism for getting common address information from a router, this is orthogonal to the question of whether a client-based mechanism for address registration is useful.   It seems to me that there are three broad classifications of use cases here:

1. In an environment where address registration is mandatory, and hosts are tightly controlled, this protocol may suffice.
2. In an environment where address registration is optional/advisory, this protocol may suffice, since presumably the reason you register addresses is to track client-sourced information like hostname that relates to the address.
3. In an environment where address registration is mandatory and hosts are not tightly controlled, you need support for address registration on the router.   However, you can _still_ benefit in this case from the DHCP-based address registration protocol; devices that support it can still provide hints about the FQDN they want.

I point this out because the reason I support this draft is the FQDN use case.   This is a use case that has seen substantial use in enterprise environments in IPv4.   We do not currently have a solution to the problem for IPv6, because in IPv6 we don't require DHCP for host configuration.   This DHCP extension allows us to leverage a DHCP infrastructure without _requiring_ that hosts autoconfigure using DHCP, and without even _requiring_ that hosts register their addresses at all.

I think Sheng has a different use case in mind, and from what I can tell his use case falls into the first category, where mine falls into the second.   I know of other enterprise users who have use cases that fall into category 3; for them, this protocol will not be sufficient, and they will need the router-based protocol either instead, or as well.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2012 13:45:48 +0000

On Nov 16, 2012, at 4:36 AM, Sten Carlsen <[email-masked]> wrote:
> This leads to my question: is this setup taken into account presently? Is there a clear cut in the system allowing for this division.  I should be able to read this myself but time has not allowed for that and I have not seen this in the discussions.

It's a specific intent of the DHC working group that this document cover the DHCP/DNS update use case.   It would be good if you could read the document and assure yourself that it does in fact cover that case—more review is always better.

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 16 Nov 2012 19:28:39 +0100

I see this document is really describing a tightly controlled setup, 
whereas I was looking for a kind of two-tier management setup.

I was concerned with how it would work in the following setup:

Internet --a-- ISP --b-- SOHO --c-- a number of hosts

In link "a" the ISP is given a large address area from IANA one or more 
/48 prefixes.
In link "b" the ISP hands one /64 prefix on to a small company, (SOHO) 
these addresses should be given out to the various hosts in the SOHO 
network and their names/IPs should be registered in the SOHO's own DNS 
and not be registered in the ISP's DNS but potentially in the router 
access tables to be allowed out.
Link "c" is the SOHO internal network, this should be controlled solely 
by the SOHO.

So given my level of understanding here I would like to ask where you 
see this draft used?
1 - Is it used by the ISP to control the SOHO hosts, I think that is not 
a good solution.
2 - Is it used by the SOHO to control his own hosts, that would be fine, 
except if the ISP needs to know which hosts are allowed to access the 
internet.
3 - Is it used on link "b" only to control the router at the edge of the 
SOHO and keep track of the ISPs own network units?

I believe #3 on my list is the best place to use this new capability, #2 
is also very much in line with the goals and intentions of a well 
managed SOHO.

 From my reading it looks like is is much more geared towards #1, which 
I feel would be a big mistake. It would prevent the SOHO from actually 
managing their own hosts.

As mentioned before I can easily have missed one point here or maybe 
this document is not suited to be used in this situation but some other 
document is written to cover this situation.

I found a language problem, I believe. At the end of chapter 3 I find 
this paragraph, which I think needs a bit tweaking:

  By received the acknowledgement, the host can continue use the
    registered address.  It SHOULD use the assigned preferred and valid
    lifetime for the correspondeding address.

-- 
Best regards

Sten Carlsen

        "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Nov 2012 18:51:20 +0000

On Nov 16, 2012, at 1:28 PM, Sten Carlsen <[email-masked]>
 wrote:
> So given my level of understanding here I would like to ask where you see this draft used?
> 1 - Is it used by the ISP to control the SOHO hosts, I think that is not a good solution.

The ISP DHCP server never talks directly to SOHO hosts, so I don't see how this solution could be implemented.   Remember that the SOHO router is getting a prefix delegation from the ISP; it is by definition responsible for managing addresses on that /64.

> 2 - Is it used by the SOHO to control his own hosts, that would be fine, except if the ISP needs to know which hosts are allowed to access the internet.

I've never heard of an ISP filtering access to a limited number of hosts on a wire.   I don't think that is practical, since it would break temporary addresses.

> 3 - Is it used on link "b" only to control the router at the edge of the SOHO and keep track of the ISPs own network units?

This is the only model that makes any sense to me.

---

From: Sten Carlsen <[email-masked]>
Date: Fri, 16 Nov 2012 20:29:54 +0100

> The ISP DHCP server never talks directly to SOHO hosts, so I don't see how this solution could be implemented.   Remember that the SOHO router is getting a prefix delegation from the ISP; it is by…
Good, what I hoped for. With IPv4 it is sometimes a bit different - one 
might fear that habits follow to next technology.
> I've never heard of an ISP filtering access to a limited number of hosts on a wire.   I don't think that is practical, since it would break temporary addresses.
This does happen with IPv4, addresses are sparse and one might fear that 
the same habit could go to IPv6 - "You want three PCs talking to the 
internet, pay three slots".
The answer I hoped for.
> This is the only model that makes any sense to me.
I fully agree, this does make sense to me. Every link can use it to 
manage their own part of the chain but not more links.
Thanks for taking the time to answer my questions.

-- 
Best regards

Sten Carlsen

        "MALE BOVINE MANURE!!!"

---

From: Tim Chown <[email-masked]>
Date: Sat, 17 Nov 2012 12:18:05 +0000

On 16 Nov 2012, at 23:49, Mark Smith <[email-masked]> wrote:

> Hi,
> 
> I think there are advantages to keeping the mechanisms to collect information
> about hosts and their addresses independent of how those addresses are
> assigned or derived. 

I think this is a fair point.

I also can't help but think that there is likely to be some overlap between what this draft is trying to do, and what we might end up with as a result of the homenet and/or mdnsext work in extending zeroconf methods to home and enterprise/campus networks.

Simply for address usage tracking, we've found it sufficient to run tools that poll the switch/router infrastructure. We do that on a campus using open source tools and it works just fine, provided the polling is configured to take into account the expiration timers of the data being gathered from the devices. Where the tool is also aware of the all the network devices, their connectivity, prefix allocations, VLANs, switch port configurations, etc, then you have pretty much all you need for accountability. We also use 802.1X for wireless (eduroam) and are beginning to use it for wired ports as well.

I've not looked at Fernando's tool. I would assume it achieves the same thing in terms of address tracking, but I'd argue that integrating the polling/tracking with network monitoring/management tools that have the 'bigger picture' is advantageous.

Tim

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Nov 2012 22:31:28 -0800 (PST)

I haven't had a chance to run Fernando's utility, however I understand it implements address recording using observation.

http://www.si6networks.com/tools/ipv6mon/

----- Original Message -----
> From: Sheng Jiang <[email-masked]>
> To: joel jaeggli <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; IPv6 Ops WG <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Friday, 16 November 2012 5:11 PM
> Subject: Re: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01
> 
> Yes, it was not in the document. Since this document is a DHC draft, we focused 
> on the DHCP Protocol interaction and option definition. We did not do very well 
> to describe suitable scenarios until recently. We will work on that. Thanks to 
> help us improve the document.
> 
> Agree, more information should be provided in the case of reject address. 
> Actually, the specific case of denying CGA with low sec-value was solved by 
> another dedicated draft 
> (http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6) , in which a new 
> DHCPv6 option has been defined to feedback a recommended Sec value.
> 
> managing

---

From: Mark Smith <[email-masked]>
Date: Fri, 16 Nov 2012 15:49:14 -0800 (PST)

Hi,

----- Original Message -----
> From: Ted Lemon <[email-masked]>
> To: Mark Smith <[email-masked]>
> Cc: Sheng Jiang <[email-masked]>; joel jaeggli <[email-masked]>; "[email-masked]" <[email-masked]>; IPv6 Ops WG <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Saturday, 17 November 2012 12:40 AM
>>  I agree with Joel, I think observation by most likely a router is a better 
> method, as it will capture address information regardless of whether it was 
> configured via static, SLAAC or DHCPv6 (or any future methods).
> 
> It's certainly true that a router can capture all the IPv4 and IPv6 
> addresses that a device with a particular MAC address uses.   However, what a 
> router _can't_ do, and what this option allows to be done, is for a device 
> that has autoconfigured to then provide the network administrator with a hint as 
> to what its FQDN should be.   This information isn't available to the 
> router.
> 
> It seems to me that although it is true that it is worthwhile to define a 
> mechanism for getting common address information from a router, this is 
> orthogonal to the question of whether a client-based mechanism for address 
> registration is useful.   It seems to me that there are three broad 
> classifications of use cases here:
> 
> 1. In an environment where address registration is mandatory, and hosts are 
> tightly controlled, this protocol may suffice.
> 2. In an environment where address registration is optional/advisory, this 

> protocol may suffice, since presumably the reason you register addresses is to 
> track client-sourced information like hostname that relates to the address.
> 3. In an environment where address registration is mandatory and hosts are not 
> tightly controlled, you need support for address registration on the router.  
> However, you can _still_ benefit in this case from the DHCP-based address 
> registration protocol; devices that support it can still provide hints about the 
> FQDN they want.
> 
> I point this out because the reason I support this draft is the FQDN use case.  
> This is a use case that has seen substantial use in enterprise environments in 
> IPv4.   We do not currently have a solution to the problem for IPv6, because in 
> IPv6 we don't require DHCP for host configuration.   This DHCP extension 
> allows us to leverage a DHCP infrastructure without _requiring_ that hosts 
> autoconfigure using DHCP, and without even _requiring_ that hosts register their 
> addresses at all.
> 
> I think Sheng has a different use case in mind, and from what I can tell his use 
> case falls into the first category, where mine falls into the second.   I know 
> of other enterprise users who have use cases that fall into category 3; for 
> them, this protocol will not be sufficient, and they will need the router-based 
> protocol either instead, or as well.
> 

It seems to me that either RFC3122 - "Extensions to IPv6 Neighbor Discovery

for Inverse Discovery Specification" and/or RFC4620 - "IPv6 Node Information
Queries" might be able to meet those needs. Where they considered?

I think there are advantages to keeping the mechanisms to collect information
about hosts and their addresses independent of how those addresses are
assigned or derived. For example, it seems that it might be valid to have
a host use both SLAAC (i.e. PIO with the A bit on) and DHCPv6 (RA with the
M bit on) to configure it's addresses, as the M bit doesn't say that A bits
in PIOs must be ignored or vice versa. While a link will usually use one or the other
of the methods, the use case is a period of transition between the two
e.g. moving from SLAAC to DHCPv6. There is some evidence that Windows 7
has adopted the exclusive one or the other approach to SLAAC and DHCPv6,
and that is causing an issue when there is a later RA that has a different M
bit value i.e. the later RA has the M bit switched off, to move the subnet
from DHCPv6 address assignment to SLAAC based assignment, and the DHCPv6
addresses are being expired immediately, regardless of the preferred and
valid lifetimes that the DHCPv6 server announced. In other words, instead
of being able to do a phased and gradual transition from DHCPv6 to SLAAC
via preferred and valid lifetimes, this is forcing a disruptive change.

Static addresses, and Tokenised IPv6 identifiers
(http://tools.ietf.org/html/draft-chown-6man-tokenised-ipv6-identifiers-02)
would also be a reason to try to use address and host information query
methods that are address configuration method independent.

Regards,
Mark.

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 19 Nov 2012 03:03:32 +0000

>From: Ted Lemon [mailto:[email-masked]]
>Sent: Friday, November 16, 2012 9:41 PM
>To: Mark Smith
>Cc: Sheng Jiang; joel jaeggli; [email-masked]; IPv6 Ops WG;
>[email-masked]
>It's certainly true that a router can capture all the IPv4 and IPv6 addresses
>that a device with a particular MAC address uses.   However, what a router
>_can't_ do, and what this option allows to be done, is for a device that has
>autoconfigured to then provide the network administrator with a hint as to
>what its FQDN should be.   This information isn't available to the router.
>
>3. In an environment where address registration is mandatory and hosts are
>not tightly controlled, you need support for address registration on the router.
>IPv4.   We do not currently have a solution to the problem for IPv6, because
>in IPv6 we don't require DHCP for host configuration.   This DHCP extension
>autoconfigure using DHCP, and without even _requiring_ that hosts register
>their addresses at all.
>

Hi, Ted,

Thanks for your email. Yes, my original use case falls into the first category. However, since we are trying to define a generic addr registration mechanism, we could include more applicable use cases. I guess what we should do now is to add a "Applicability" section into the draft. Are you interested and have time to contribute some text?

For me, router-based addr registration may need another dedicated draft. Although current IA can work out, a new DHCP option that support bulk addr registration may be more efficient than one addr per time. What's your opinion?

Best regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Nov 2012 03:14:10 +0000

> Thanks for your email. Yes, my original use case falls into the first category. However, since we are trying to define a generic addr registration mechanism, we could include more applicable use ca…

I can try.   I have a lot of things on my list.   :}

> For me, router-based addr registration may need another dedicated draft. Although current IA can work out, a new DHCP option that support bulk addr registration may be more efficient than one addr…

I think that bulk registration won't work because hosts aren't discovered all at the same time; either the router waits until it's accumulated enough to fill a packet, or it sends an update each time it discovers a new one.

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 19 Nov 2012 05:58:58 +0000

Hi, Sten,

Thanks for your interests and email. Actually, the draft does target some scenario close to #3, but replace SOHO router by enterprise router, ISP edge router, or hotspot router. These routers advertise prefixes. The addr registration server may be located somewhere in a or b.

The language problem has been recorded and will be improved in next update.

Many thanks and best regards,

Sheng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sten Carlsen
Sent: Saturday, November 17, 2012 2:29 AM
To: Ted Lemon
Cc: <[email-masked]>
Subject: Re: [dhcwg] [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01

I see this document is really describing a tightly controlled setup, whereas I was looking for a kind of two-tier management setup.

In link "a" the ISP is given a large address area from IANA one or more /48 prefixes.
In link "b" the ISP hands one /64 prefix on to a small company, (SOHO) these addresses should be given out to the various hosts in the SOHO network and their names/IPs should be registered in the SOHO's own DNS and not be registered in the ISP's DNS but potentially in the router access tables to be allowed out.
Link "c" is the SOHO internal network, this should be controlled solely by the SOHO.

I believe #3 on my list is the best place to use this new capability, #2 is also very much in line with the goals and intentions of a well managed SOHO.

From my reading it looks like is is much more geared towards #1, which I feel would be a big mistake. It would prevent the SOHO from actually managing their own hosts.

As mentioned before I can easily have missed one point here or maybe this document is not suited to be used in this situation but some other document is written to cover this situation.

I found a language problem, I believe. At the end of chapter 3 I find this paragraph, which I think needs a bit tweaking:

On Nov 16, 2012, at 4:36 AM, Sten Carlsen <[email-masked]><mailto:[email-masked]> wrote:

--

Best regards

Sten Carlsen

       "MALE BOVINE MANURE!!!"

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 19 Nov 2012 06:27:00 +0000

>I think this is a fair point.

Tim and Mark,

Although we used DHCPv6 protocol to carry the addr registration information. The procedure is not necessary to be mixed with the way those addresses are assigned or derived. They are independent operations.

>I also can't help but think that there is likely to be some overlap between what
>this draft is trying to do, and what we might end up with as a result of the
>homenet and/or mdnsext work in extending zeroconf methods to home and
>enterprise/campus networks.

I don't understand why we should make way to future work which has not happen yet. They may use our output if there is overlap.

>Simply for address usage tracking, we've found it sufficient to run tools that
>poll the switch/router infrastructure. We do that on a campus using open
>source tools and it works just fine, provided the polling is configured to take
>into account the expiration timers of the data being gathered from the
>devices. Where the tool is also aware of the all the network devices, their
>connectivity, prefix allocations, VLANs, switch port configurations, etc, then
>you have pretty much all you need for accountability. We also use 802.1X for
>wireless (eduroam) and are beginning to use it for wired ports as well.

I have no doubt tools with their private protocol can complete the work too. Here, we are trying to use a standard protocol to carry the information. This would also benefit for various implementations.

Best regards,

Sheng

>I've not looked at Fernando's tool. I would assume it achieves the same thing
>in terms of address tracking, but I'd argue that integrating the polling/tracking
>with network monitoring/management tools that have the 'bigger picture' is
>advantageous.
>
>Tim

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 19 Nov 2012 06:59:08 +0000

>> For me, router-based addr registration may need another dedicated draft.
>>Although current IA can work out, a new DHCP option that support bulk addr
>>registration may be more efficient than one addr per time. What's your
>>opinion?
>
>I think that bulk registration won't work because hosts aren't discovered all at
>the same time; either the router waits until it's accumulated enough to fill a
>packet, or it sends an update each time it discovers a new one.

Make sense. So, we will expand the current addr registration to be client-based model, in which the client maybe router.

Sheng