headers
Pekka Savola | 1 Aug 2004 17:03
Picon

mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

Hi, 

A few comments.

Bigger ones:

 1) I'm concerned whether this is exactly what we need, especially when we
have RFC3306 or embedded-RP; it is not clear which problem we're solving
(and which problems remain to be solved).

In particular, if any host on a link with a /64 prefix could calculate its
own multicast prefix (unique to that link) on its own, and have 32 bits of
group-id's to pick from (making sure they don't conflict on that link),
could one argue that there is no need for central multicast address
assignment.. but rather a mechanism where the host could pick a group-id in
such a way it doesn't conflict (a random process should be sufficient, but
if not, there could be Multicast DAD)?

Similarly, if embedded-RP is used, what you could need is the information
what is the address of the RP or which prefix one should use for picking the
multicast addresses.

So, looking at from a different perspective, it would seem that we don't
necessarily need DHCPv6 for address assignment itself, but maybe some other
configuration mechanism to figure out the multicast prefix which belongs on
the link.

Remember, we're talking about v6 here which is completely different than v4
multicast address assignment scenarios (address scarcity, centrally managed
pool, etc.)!
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stig Venaas | 1 Aug 2004 19:44
Picon
Picon

Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

On Sun, Aug 01, 2004 at 06:03:48PM +0300, Pekka Savola wrote:
[...]
> have RFC3306 or embedded-RP; it is not clear which problem we're solving
> (and which problems remain to be solved).
> 
> In particular, if any host on a link with a /64 prefix could calculate its
> own multicast prefix (unique to that link) on its own, and have 32 bits of
> group-id's to pick from (making sure they don't conflict on that link),
> could one argue that there is no need for central multicast address
> assignment.. but rather a mechanism where the host could pick a group-id in
> such a way it doesn't conflict (a random process should be sufficient, but
> if not, there could be Multicast DAD)?

Yes, I've also thought a bit about this. The 64-bit link-id could be a
starting point too. I think some form of DAD would be nice. It must also
be possible for a host to have multiple groups.

> Similarly, if embedded-RP is used, what you could need is the information
> what is the address of the RP or which prefix one should use for picking the
> multicast addresses.
> 
> So, looking at from a different perspective, it would seem that we don't
> necessarily need DHCPv6 for address assignment itself, but maybe some other
> configuration mechanism to figure out the multicast prefix which belongs on
> the link.

Yes, sounds good. So question then is whether DHCP or something else
should be used. WRT Embedded-RP I think allocating a prefix to the link,
as you suggest, is better than telling the application what the
Embedded-RP address is (applications shouldn't need to know about
(Continue reading)

Permalink | Reply | 6 comments |
headers
Van Aken Dirk | 1 Aug 2004 20:49

RE: Comments ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-imap-00.txt

Hello Ted, Cristian,

See some comments inline.

Best regards - Dirk

> -----Original Message-----
> From: dhcwg-bounces <at> ietf.org 
> [mailto:dhcwg-bounces <at> ietf.org]On Behalf Of
> Ted Lemon
> Sent: vrijdag 30 juli 2004 18:33
> To: Cristian Cadar
> Cc: dhcwg <at> ietf.org
> Subject: Re: [dhcwg] Comments
> ondraft-cadar-dhc-dhcpv6-opt-email-00.txt/draft-cadar-dhc-opt-
> imap-00.txt
>  
> I guess my first question about this is why?

I assume to come closer to zero-config of hosts and applications I would say.

> Why would you want a client to trust the DHCP server to tell you what IMAP server to 
> contact?

Is this not true for all options that are returned by a server ?

>  What if you wind up talking to a rogue server, or roam to a 
> different network?   These don't seem like things that are 
> location-dependent - they seem like things that you want to configure 
> on the client and not change as the client moves around.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pekka Savola | 2 Aug 2004 00:01
Picon

Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

On Sun, 1 Aug 2004, Stig Venaas wrote:
[...]
> I see some possible issues. There might be a need for giving hosts
> different prefixes for different scopes (you could imagine having
> one prefix where simply the scope bits are set to whatever scope
> is needed). I think there are cases where you might use say
> Embedded-RP internally (with small scope) and prefix-based addressing
> externally (with larger scope) or vice versa. Or where you may want
> different RPs for different scopes.

Well, one obvious way to achieve all of this is to add a Multicast
Prefix Information option (a tailed down version of PI option), to
RFC2461/RFC2462 Route Advertisements, and specification of multicast
DAD (possibly with a flag in the MPI whether it's needed or not).

With that, multiple prefixes could be advertised, but typically one
would be enough.

(The "good news" here is that a good implementation would not need to 
require the router admin to specify the prefix to be advertised on all 
the links, but it could be calculated & advertised automatically as 
well.)

Additionally, individual addresses could also be dealt with DHCPv6 or
something, but I personally don't see that as equally attractive.. but
in cases where this is attractive IMHO manual addressing, as it's done
today, is probably typically more lucrative..

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ralph Droms | 2 Aug 2004 03:57
Picon
Favicon

Final agenda for dhc WG meeting

PLEASE READ THE INTERNET DRAFTS ON THE AGENDA!!!!  We need active
participants, who have read the drafts BEFORE the WG meeting, so we can
reach consensus on WG actions such as accepting drafts as WG work items and
approving drafts for WG last call.

We will need at least one 9and preferably more) scribe to take notes at the
meeting.

Is anyone who will not attend the meeting in San Diego interested in a
jabber session?  Please let me know as soon as possible.

Final agenda:

                           DHC WG agenda - IETF 60
                       0900 Tue 2004-08-03 (tentative)
                      (Last revised 08/01/2004 09:48 PM)
                      ----------------------------------

Administrivia                                      Ralph Droms      10 minutes
   Agenda bashing, blue sheets, scribe, Jabber scribe
   Status of IPR claim by Samsung on draft-ietf-dhc-rapid-commit-opt-05.txt
   Status of IPR claim by PacketFront on draft-ietf-dhc-subscriber-id-06.txt
   Request for milestones for dhc WG drafts

The DHCPv6 Client FQDN Option                      Bernie Volz      05 minutes
   <draft-volz-dhc-dhcpv6-fqdn>
   Accept as dhc WG work item?

The DHCP Client FQDN Option                        Bernie Volz      10 minutes
   <draft-ietf-dhc-fqdn-option>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stig Venaas | 2 Aug 2004 06:48
Picon
Picon

Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote:
[...]
> Well, one obvious way to achieve all of this is to add a Multicast
> Prefix Information option (a tailed down version of PI option), to
> RFC2461/RFC2462 Route Advertisements, and specification of multicast
> DAD (possibly with a flag in the MPI whether it's needed or not).
> 
> With that, multiple prefixes could be advertised, but typically one
> would be enough.
> 
> (The "good news" here is that a good implementation would not need to 
> require the router admin to specify the prefix to be advertised on all 
> the links, but it could be calculated & advertised automatically as 
> well.)

The prefixes to use could also be announced by DHCP. You could easily
use stateless DHCP. In addition to this some form of DAD would be good.
I don't care that much how the client picks the last 32 bits, it could
be random, from interface id somehow, or specified by the user. The
main thing is making sure it's unique.

So, I think there are basically two issues that can be solved
independently. One is prefix to use, the other is link uniqueness.

The former might be done with RAs or stateless DHCP. The second
should probably be done using some link-local multicast ICMP, but I
need to think more about that. One issue is that one needs to allow
multiple sources for a group in some cases. So I think DAD should
just be offered as a service, whether an application should use the
group in case of duplicates should be up to the application.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Strauf | 2 Aug 2004 08:26
Picon
Favicon

Re: Final agenda for dhc WG meeting


> Is anyone who will not attend the meeting in San Diego interested in a
> jabber session?  Please let me know as soon as possible.
I'm very interested in a jabber scribe. Thanks in advance!

Christian
Permalink | Reply | 0 comments |
headers
Jean-Jacques Pansiot | 2 Aug 2004 11:35
Picon
Picon

Re: mboned: draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00 comments

Stig Venaas wrote:

>On Mon, Aug 02, 2004 at 01:01:06AM +0300, Pekka Savola wrote:
>[...]
>  
>
>>Well, one obvious way to achieve all of this is to add a Multicast
>>Prefix Information option (a tailed down version of PI option), to
>>RFC2461/RFC2462 Route Advertisements, and specification of multicast
>>DAD (possibly with a flag in the MPI whether it's needed or not).
>>
>>With that, multiple prefixes could be advertised, but typically one
>>would be enough.
>>
>>(The "good news" here is that a good implementation would not need to 
>>require the router admin to specify the prefix to be advertised on all 
>>the links, but it could be calculated & advertised automatically as 
>>well.)
>>    
>>
>
>The prefixes to use could also be announced by DHCP. You could easily
>use stateless DHCP. In addition to this some form of DAD would be good.
>I don't care that much how the client picks the last 32 bits, it could
>be random, from interface id somehow, or specified by the user. The
>main thing is making sure it's unique.
>  
>
One useful feature of DHCP  is the notion of  a lease for some amount of 
time.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart Cheshire | 2 Aug 2004 21:49
Picon
Favicon

Re: Gratuitous ARP in DHCP vs. IPv4 ACD Draft

>I think it's worth having a standard that says what the right thing to 
>do is.   Stuart's draft seemed like a good candidate, but did not get 
>widespread support from the DHC working group, if I remember correctly.

I would say it got luke-warm support.

I plan to update the draft, as soon as I get time.

>   There was also some question as to whether it was even on-topic for 
>the working group, since it actually changes the semantics of ARP 
>somewhat.

No, it doesn't change ARP semantics in any way. Everything it recommends 
is 100% consistent with RFC 826.

The question of whether to announce via ARP request or response is 
something that really doesn't matter, and is therefore the thing 
guaranteed to generate the greatest amount of debate. As John Schnizlein 
correctly pointed out, "RFC 826 explicitly does not discriminate between 
request or reply messages before updating its table".

Here's what I plan to put in the next draft:

Why are ARP Announcements performed using ARP Request packets and not
ARP Reply packets?

There are two reasons, one is historical precedent, and the other is
practicality.

The historical precedent is that Gratuitous ARP is described in Stevens
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stuart Cheshire | 2 Aug 2004 21:55
Picon
Favicon

Re: Gratuitous ARP in DHCP vs. IPv4 ACD Draft

>"Ongoing conflict detection and defense" appears an unnecessary
>overhead unless hosts make up addresses rather than relying on
>a simple allocator such as DHCP to assign them. It would have
>been easy enough to define an initial election mechanism for 
>which host on a subnet, lacking a DHCP server, should provide
>simple address allocation. The result would be a tiny amount
>of extra work for one host instead of all the "ongoing conflict 
>detection and defense" for all hosts.

I really don't know what overhead you're talking about.

There are no extra packets to do ongoing conflict detection (and no 
change to existing packets). If you mean CPU overhead, there really isn't 
any, because this is just a tiny refinement to the existing code path for 
handling received ARP packets. All the draft says is that if you see 
someone else broadcast an ARP packet, and when you go to update your ARP 
cache you find that it's YOUR OWN IP address that you're about to update 
to point to some other machine's hardware address, that's bad news, and 
you probably shouldn't ignore it. That's all: When you observe that the 
network is broken, then you should at least alert the user in some way so 
that they have an idea what is wrong.

Stuart Cheshire <cheshire <at> apple.com>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org
Permalink | Reply | 0 comments |

Gmane