Two parts to this one:
1. Are we agreed that the normal response should be to unicast in
response to RSs and that multicast is for dealing with exceptional
circumstances and for unsolicited RAs or dealing with RSs with the
unspecified source address?
2. When multicasting because of lack of unicast tokens, should we
say simply say that the gap bewteen multicast RAs should not be
less than 3 seconds as per rfc2461, meaning that if no multicast
RAs have been sent in the last three seconds then it will be sent
immediately, OR should we specify a delay?
If a delay, then should it be small (10s of milliseconds), larger,
or three seconds?
>Two parts to this one:
>>
>> 1. Are we agreed that the normal response should be to unicast in
>> response to RSs and that multicast is for dealing with exceptional
>> circumstances and for unsolicited RAs or dealing with RSs with the
>> unspecified source address?
>>
Yes.
>> 2. When multicasting because of lack of unicast tokens, should we
>> say simply say that the gap bewteen multicast RAs should not be
>> less than 3 seconds as per rfc2461, meaning that if no multicast
>> RAs have been sent in the last three seconds then it will be sent
>> immediately, OR should we specify a delay?
>>
>> If a delay, then should it be small (10s of milliseconds), larger,
>> or three seconds?
>>
I think we should specify that the starting point for the timer should be
the last unicast RA, not the last multicast RA. 3 seconds seems a little
long for a default, I think 500 ms to 1 sec should do (10s of msec is too
short for heavy load and DoS attack circumstances, IMHO), but I don't have
any problem with staying with 3 sec as long as we indicate that it is a
default and should be tuned to deployment circumstances.
jak
Brett Pentland wrote:
> Two parts to this one:
>
> 1. Are we agreed that the normal response should be to unicast in
> response to RSs and that multicast is for dealing with exceptional
> circumstances and for unsolicited RAs or dealing with RSs with the
> unspecified source address?
Except RSes with the unspecified source address and TSLLAO option, which can receive a unicast responses.
> 2. When multicasting because of lack of unicast tokens, should we
> say simply say that the gap bewteen multicast RAs should not be
> less than 3 seconds as per rfc2461, meaning that if no multicast
> RAs have been sent in the last three seconds then it will be sent
> immediately, OR should we specify a delay?
>
> If a delay, then should it be small (10s of milliseconds), larger,
> or three seconds?
Three seconds is good enough for me, and we can add a note to the draft saying:
DISCUSSION: should we make this shorter?
so that we can engage the WG on some of these issues.
Erik
James Kempf wrote: > I think we should specify that the starting point for the timer should be > the last unicast RA, not the last multicast RA. 3 seconds seems a little > long for a default, I think 500 ms to 1 sec should do (10s of msec is too > short for heavy load and DoS attack circumstances, IMHO), but I don't have > any problem with staying with 3 sec as long as we indicate that it is a > default and should be tuned to deployment circumstances. That's ok with me as well. Should we also suggest that the max multicast RA rate (of one every 3 seconds) is something that can be adjusted based on the deployment and link performance? Erik
>> 2. When multicasting because of lack of unicast tokens, should we >> say simply say that the gap bewteen multicast RAs should not be >> less than 3 seconds as per rfc2461, meaning that if no multicast >> RAs have been sent in the last three seconds then it will be sent >> immediately, OR should we specify a delay? >> >> If a delay, then should it be small (10s of milliseconds), larger, >> or three seconds? >> > > > I think we should specify that the starting point for the timer should be > the last unicast RA, not the last multicast RA. 3 seconds seems a little > long for a default, I think 500 ms to 1 sec should do (10s of msec is too > short for heavy load and DoS attack circumstances, IMHO), but I don't have > any problem with staying with 3 sec as long as we indicate that it is a > default and should be tuned to deployment circumstances. Sounds fine.
Erik Nordmark wrote: > Brett Pentland wrote: > >> Two parts to this one: >> >> 1. Are we agreed that the normal response should be to unicast in >> response to RSs and that multicast is for dealing with exceptional >> circumstances and for unsolicited RAs or dealing with RSs with the >> unspecified source address? > > > > Except RSes with the unspecified source address and TSLLAO option, which can receive a unicast responses. Do we really want to send a unicast response to a host with no unicast address? > >> 2. When multicasting because of lack of unicast tokens, should we >> say simply say that the gap bewteen multicast RAs should not be >> less than 3 seconds as per rfc2461, meaning that if no multicast >> RAs have been sent in the last three seconds then it will be sent >> immediately, OR should we specify a delay? >> >> If a delay, then should it be small (10s of milliseconds), larger, >> or three seconds? > > > > > Three seconds is good enough for me, and we can add a note to the draft saying: > DISCUSSION: should we make this shorter? > so that we can engage the WG on some of these issues. Sounds fine to me or with Jim's suggestion to start the timer from the last unicast RA; I don't mind. Brett.
>James Kempf wrote: >> > >>> > I think we should specify that the starting point for the timer should be >>> > the last unicast RA, not the last multicast RA. 3 seconds seems a little >>> > long for a default, I think 500 ms to 1 sec should do (10s of msec is too >>> > short for heavy load and DoS attack circumstances, IMHO), but I don't have >>> > any problem with staying with 3 sec as long as we indicate that it is a >>> > default and should be tuned to deployment circumstances. > >> >> That's ok with me as well. I agree. >> >> Should we also suggest that the max multicast RA rate (of one every 3 >> seconds) is something that can be adjusted based on the deployment and >> link performance? That could be a good idea. I think that gives more flexibility for those who like fine tuning. Tero
Erik's suggestion of a discussion item for the WG sounds OK. Someone in the
WG may have a strong opinion on it.
jak
----- Original Message -----
From: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
To: "Erik Nordmark" <erik.nordmark@sun.com>
Cc: <dna-dt@eng.monash.edu.au>
Sent: Tuesday, April 19, 2005 1:14 AM
Subject: Re: [DNA-DT] Solution1, Issue 1: Unicast vs. multicast transmission
of RAs
>> Erik Nordmark wrote:
>
>>> > Brett Pentland wrote:
>>> >
>>
>>>> >> Two parts to this one:
>>>> >>
>>>> >> 1. Are we agreed that the normal response should be to unicast in
>>>> >> response to RSs and that multicast is for dealing with exceptional
>>>> >> circumstances and for unsolicited RAs or dealing with RSs with the
>>>> >> unspecified source address?
>>
>>> >
>>> >
>>> > Except RSes with the unspecified source address and TSLLAO option, which
>>> > can receive a unicast responses.
>
>>
>> Do we really want to send a unicast response to a host with no unicast
>> address?
>
>>> >
>>
>>>> >> 2. When multicasting because of lack of unicast tokens, should we
>>>> >> say simply say that the gap bewteen multicast RAs should not be
>>>> >> less than 3 seconds as per rfc2461, meaning that if no multicast
>>>> >> RAs have been sent in the last three seconds then it will be sent
>>>> >> immediately, OR should we specify a delay?
>>>> >>
>>>> >> If a delay, then should it be small (10s of milliseconds), larger,
>>>> >> or three seconds?
>>
>>> >
>>> >
>>> >
>>> > Three seconds is good enough for me, and we can add a note to the draft
>>> > saying:
>>> > DISCUSSION: should we make this shorter?
>>> > so that we can engage the WG on some of these issues.
>
>>
>> Sounds fine to me or with Jim's suggestion to start the timer from the
>> last unicast RA; I don't mind.
>>
>> Brett.
>>
Brett Pentland wrote: > Erik Nordmark wrote: >> Except RSes with the unspecified source address and TSLLAO option, which can receive a unicast responses. > > > > Do we really want to send a unicast response to a host with no unicast > address? Isn't that what TSSLAO is advocating? Or is TSSLAO assuming that the source address of the RS would be the (possibly duplicate) link-local address? Yes, I think so. Sorry for the confusion. Erik
Erik,
I think you've hit on a broader issue. What unicast IPv6 address should the
host use as the source address on the RS?
The quick and obvious answer is: "it's (or a) link local address" as you
say. This address will be topologically correct on both an old and new link.
But the problem is, if the host has moved to a new link, the link local
address might be a duplicate. So should the host, upon any link move, back
off on the state machine for DAD for the (a) link local address from
"Confirmed" to "Optimistic" (assuming oDAD). And what about a statefully
assigned address? I don't believe there is any requirement for hosts to have
a link local address if they are statefully configured (though they must DAD
any DHCP configured addresses).
As a practical matter, the IPv6 address is not used on the last hop for
routing. If the router has a link address (even at TSLLA), the RA will get
back to the host. There is a security issue, in that the router cannot
identify, by IP address, a packet with the unspecified address, and there
may be some constraints involved in how the unspecified address can be used,
but it certainly won't make any difference w.r.t. routing the RA back to the
host.
jak
----- Original Message -----
From: "Erik Nordmark" <erik.nordmark@sun.com>
To: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
Cc: <dna-dt@eng.monash.edu.au>
Sent: Tuesday, April 19, 2005 6:37 PM
Subject: Re: [DNA-DT] Solution1, Issue 1: Unicast vs. multicast transmission
of RAs
>> Brett Pentland wrote:
>
>>> > Erik Nordmark wrote:
>
>>
>
>>>> >> Except RSes with the unspecified source address and TSLLAO option,
>>>> >> which can receive a unicast responses.
>>
>>> >
>>> >
>>> > Do we really want to send a unicast response to a host with no unicast
>>> > address?
>
>>
>> Isn't that what TSSLAO is advocating?
>> Or is TSSLAO assuming that the source address of the RS would be the
>> (possibly duplicate) link-local address? Yes, I think so.
>>
>> Sorry for the confusion.
>>
>> Erik
>>
>>
James Kempf wrote: > Erik, > > I think you've hit on a broader issue. What unicast IPv6 address should the > host use as the source address on the RS? > > The quick and obvious answer is: "it's (or a) link local address" as you > say. This address will be topologically correct on both an old and new link. > But the problem is, if the host has moved to a new link, the link local > address might be a duplicate. So should the host, upon any link move, back > off on the state machine for DAD for the (a) link local address from > "Confirmed" to "Optimistic" (assuming oDAD). And what about a statefully > assigned address? I don't believe there is any requirement for hosts to have > a link local address if they are statefully configured (though they must DAD > any DHCP configured addresses). All IPv6 interfaces must have a link-local address as far as I know. Further, I think RFC 2461 requires that the source address of an RS be either unspecified, or a link-local address. There is a suggestion of how DAD can fit with DNA in the framework document (which I'm about to submit an updated version of). Erik > As a practical matter, the IPv6 address is not used on the last hop for > routing. If the router has a link address (even at TSLLA), the RA will get > back to the host. There is a security issue, in that the router cannot > identify, by IP address, a packet with the unspecified address, and there > may be some constraints involved in how the unspecified address can be used, > but it certainly won't make any difference w.r.t. routing the RA back to the > host. > > jak > > ----- Original Message ----- From: "Erik Nordmark" <erik.nordmark@sun.com> > To: "Brett Pentland" <brett.pentland@eng.monash.edu.au> > Cc: <dna-dt@eng.monash.edu.au> > Sent: Tuesday, April 19, 2005 6:37 PM > Subject: Re: [DNA-DT] Solution1, Issue 1: Unicast vs. multicast transmission > of RAs > > > >> Brett Pentland wrote: >> >>> Erik Nordmark wrote: >> >> >>>> Except RSes with the unspecified source address and TSLLAO option, >>>> which can receive a unicast responses. >>> >>> >>> >>> Do we really want to send a unicast response to a host with no unicast >>> address? >> >> >> Isn't that what TSSLAO is advocating? >> Or is TSSLAO assuming that the source address of the RS would be the >> (possibly duplicate) link-local address? Yes, I think so. >> >> Sorry for the confusion. >> >> Erik
>All IPv6 interfaces must have a link-local address as far as I know.
>> Further, I think RFC 2461 requires that the source address of an RS be
>> either unspecified, or a link-local address.
>>
>> There is a suggestion of how DAD can fit with DNA in the framework
>> document (which I'm about to submit an updated version of).
>>
>> Erik
>>
Hmm, well, the framework document isn't an official WG document, and it is
expired. Don't you think it might be a good idea to discuss this in the
protocol design document?
jak
James Kempf wrote: > Hmm, well, the framework document isn't an official WG document, Hmm, the WG decided it should be one in Minneapolis. and it is > expired. Which is why I'm working on it. > Don't you think it might be a good idea to discuss this in the > protocol design document? Yes, but it also needs to be in the BCP, since the issue is the same whether or not we add protocol elements. That's why the WG decided to keep the framework doc around so that the text doesn't get lost, and then we can figure out where this text needs to go later. Erik
----- Original Message -----
From: "Erik Nordmark" <erik.nordmark@sun.com>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: "Brett Pentland" <brett.pentland@eng.monash.edu.au>;
<dna-dt@eng.monash.edu.au>
Sent: Wednesday, April 20, 2005 11:04 AM
Subject: Re: [DNA-DT] Solution1, Issue 1: Unicast vs. multicast transmission
of RAs
>> James Kempf wrote:
>>
>
>>> > Hmm, well, the framework document isn't an official WG document,
>
>>
>> Hmm, the WG decided it should be one in Minneapolis.
>>
>> and it is
>
>>> > expired.
>
>>
>> Which is why I'm working on it.
OK, I forgot, sorry. It is not on the WG page. I assume the chairs are
waiting until you get them an update.
>>
>
>>> > Don't you think it might be a good idea to discuss this in the
>>> > protocol design document?
>
>>
>> Yes, but it also needs to be in the BCP, since the issue is the same
>> whether or not we add protocol elements.
>> That's why the WG decided to keep the framework doc around so that the
>> text doesn't get lost, and then we can figure out where this text needs
>> to go later.
>>
OK.
jak
Erik Nordmark wrote: > James Kempf wrote: > >> Erik, >> >> I think you've hit on a broader issue. What unicast IPv6 address should the >> host use as the source address on the RS? >> >> The quick and obvious answer is: "it's (or a) link local address" as you >> say. This address will be topologically correct on both an old and new link. >> But the problem is, if the host has moved to a new link, the link local >> address might be a duplicate. So should the host, upon any link move, back >> off on the state machine for DAD for the (a) link local address from >> "Confirmed" to "Optimistic" (assuming oDAD). And what about a statefully >> assigned address? I don't believe there is any requirement for hosts to have >> a link local address if they are statefully configured (though they must DAD >> any DHCP configured addresses). > > > > All IPv6 interfaces must have a link-local address as far as I know. Further, I think RFC 2461 requires that the source address of an RS be either unspecified, or a link-local address. > > There is a suggestion of how DAD can fit with DNA in the framework document (which I'm about to submit an updated version of). > > Erik > So the source address should be link-local and we need optimistic DAD if we want things to happen fast. And yes, the state of the address needs to change to "optimistic". >> As a practical matter, the IPv6 address is not used on the last hop for >> routing. If the router has a link address (even at TSLLA), the RA will get >> back to the host. There is a security issue, in that the router cannot >> identify, by IP address, a packet with the unspecified address, and there >> may be some constraints involved in how the unspecified address can be used, >> but it certainly won't make any difference w.r.t. routing the RA back to the >> host. >> >> jak The address is used for routing in a sense. A link-layer address will allow the router to send the packet to the host, but the IPv6 address is needed so that the host will actually pass the packet up the stack, isn't it? Brett. >> >> ----- Original Message ----- From: "Erik Nordmark" <erik.nordmark@sun.com> >> To: "Brett Pentland" <brett.pentland@eng.monash.edu.au> >> Cc: <dna-dt@eng.monash.edu.au> >> Sent: Tuesday, April 19, 2005 6:37 PM >> Subject: Re: [DNA-DT] Solution1, Issue 1: Unicast vs. multicast transmission >> of RAs >> >> >> >>> Brett Pentland wrote: >>> >>>> Erik Nordmark wrote: >>> >>> >>> >>>>> Except RSes with the unspecified source address and TSLLAO option, >>>>> which can receive a unicast responses. >>>> >>>> >>>> >>>> >>>> Do we really want to send a unicast response to a host with no unicast >>>> address? >>> >>> >>> >>> Isn't that what TSSLAO is advocating? >>> Or is TSSLAO assuming that the source address of the RS would be the >>> (possibly duplicate) link-local address? Yes, I think so. >>> >>> Sorry for the confusion. >>> >>> Erik
>>>As a practical matter, the IPv6 address is not used on the last hop for >>>> >> routing. If the router has a link address (even at TSLLA), the RA >>>> >> will get >>>> >> back to the host. There is a security issue, in that the router cannot >>>> >> identify, by IP address, a packet with the unspecified address, and there >>>> >> may be some constraints involved in how the unspecified address can be >>>> >> used, >>>> >> but it certainly won't make any difference w.r.t. routing the RA back >>>> >> to the >>>> >> host. >>>> >> >>>> >> jak > >> >> The address is used for routing in a sense. A link-layer address will >> allow the router to send the packet to the host, but the IPv6 address >> is needed so that the host will actually pass the packet up the stack, >> isn't it? >> >> Brett. It depends on where you want to send the packet to. It goes like this: first a device driver will receive the packet and feeds it to a generic Ethernet frame type switcher which sends it to the actual protocol handler. The protocol handler, IPv6 in this case, will then deal with the packet. Router advertisement handling is usually part of the IPv6 implementation in the kernel. A quick kernel source sweep revealed that at least *BSD will throw away a packet with an unspecified IPv6 destination address. Tero
I think we have resolution on this: Don't bother to say yes, but let me know if I've mis-intrepreted: Brett Pentland wrote: > Two parts to this one: > > 1. Are we agreed that the normal response should be to unicast in > response to RSs and that multicast is for dealing with exceptional > circumstances and for unsolicited RAs or dealing with RSs with the > unspecified source address? Yes. > > 2. When multicasting because of lack of unicast tokens, should we > say simply say that the gap bewteen multicast RAs should not be > less than 3 seconds as per rfc2461, meaning that if no multicast > RAs have been sent in the last three seconds then it will be sent > immediately, OR should we specify a delay? > > If a delay, then should it be small (10s of milliseconds), larger, > or three seconds? Specify a delay. Default three seconds for now but for negotiation by the WG and configurable by the network administrator. Brett.
>The address is used for routing in a sense. A link-layer address will
>> allow the router to send the packet to the host, but the IPv6 address
>> is needed so that the host will actually pass the packet up the stack,
>> isn't it?
>>
Are you saying that a null address won't cause the packet to be passed up
the stack? I thought 2461 allowed null addresses.
jak
James Kempf wrote:
>> The address is used for routing in a sense. A link-layer address will
>> allow the router to send the packet to the host, but the IPv6 address
>> is needed so that the host will actually pass the packet up the stack,
>> isn't it?
>>
>
>
> Are you saying that a null address won't cause the packet to be passed up
> the stack? I thought 2461 allowed null addresses.
I actually though this would be mentioned in 2460, but it's not. 2461
does say in section 2.3:
unspecified address
- a reserved address value that indicates the lack of an
address (e.g., the address is unknown). It is never
used as a destination address, but may be used as a
source address if the sender does not (yet) know its
own address (e.g., while verifying an address is unused
during address autoconfiguration [ADDRCONF]). The
unspecified address has a value of 0:0:0:0:0:0:0:0.
So it doesn't say that it won't be passed up the stack if it is there,
but it does say it should never be used as a destination address.
Brett.
| Topic DNASoln1Issue001 . { Edit | Attach | Ref-By | Printable | Diffs | r1.5 | > | r1.4 | > | r1.3 | More } |
|
Revision r1.5 - 22 Apr 2005 - 02:15 GMT - Main.BrettPentland Parents: WebHome > DNASolution1 |
Copyright © 1999-2003 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback. |