Mark,
On 2011/04/27, at 7:17, Mark Smith wrote:
> Hi Arifumi,
>
> On Tue, 26 Apr 2011 20:15:31 +0900
> Arifumi Matsumoto wrote:
>
>> Mark,
>>
>> in your case, policy table should be helpful to manipulate source
>> address selection behavior for SLAAC and manually configured
>> addresses.
>>
If you are purposefully breaking existing Standards Track
specifications (which is what it sounds like you are doing) in order
to "not require IP in IP tunneling" (a local optimization), you
probably won't get much sympathy here. Certainly not from me!
Thomas
> Since RPL protocol is intended to o
Hi Thomas
Since RPL protocol is intended to operate in networks with constrained devices
and lossy, low-bandwidth links, there is a desire to not require IP-in-IP
tunnelling that is usually used for inserting routing headers. This is detailed
in the draft http://tools.ietf.org/html/draft-hui-6
Hi Arifumi,
On Tue, 26 Apr 2011 20:15:31 +0900
Arifumi Matsumoto wrote:
> Mark,
>
> in your case, policy table should be helpful to manipulate source
> address selection behavior for SLAAC and manually configured
> addresses.
>
True, although that requires actively changing the default policy
Scott,
Thanks, the minutes have been updated.
Bob
On Apr 22, 2011, at 5:56 PM, Scott Brim wrote:
>
> On Apr 20, 2011 1:04 PM, "Bob Hinden" wrote:
> >
> > The minutes for the Prague IETF 6man working group meeting are now online
> > at:
> >
> > http://www.ietf.org/proceedings/80/minutes/6m
Hi,
For your information Gorry and I have submitted new versions of
https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/
There has been no announcement of this due to a bug in the new I-D
submission tool that I tried out.
The changes in the document are really only editorial.
Cheers
Magnu
On Apr 26, 2011, at 9:10 AM, wrote:
>> -Original Message-
>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
>> Richard Hartmann
>>
>> after renaming to draft-hartmann-6man-addresspartnaming, I am still
>> waiting for feedback.
>
> Hi,
>
> I've been thinking an
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Richard Hartmann
>
> after renaming to draft-hartmann-6man-addresspartnaming, I am still
> waiting for feedback.
Hi,
I've been thinking and reading about it. I believe that if this doc will
> In the most common usage of this header, the border router inserts a
> source routing header with the full set of intermediate nodes before
> forwarding it towards the destination within the RPL network.
and then.
> Yes, we do not use IP-in-IP tunneling and instead simply insert the RH head=
>
Good clarifications. I have revised the text. Thanks!
Thomas
Hitoshi Asaeda writes:
> Hi Thomas,
> >> >> "Nodes that need to join multicast groups SHOULD also implement either
> >> >> MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]."
> >> >
> >> > Is there a short (less than one page) descri
Mark,
in your case, policy table should be helpful to manipulate source
address selection behavior for SLAAC and manually configured
addresses.
As the final tie breaker, I do not see much sense to use preferred
lifetime for that purpose. Indefinite lifetime does not always mean
high preference. R
11 matches
Mail list logo