On 25/10/2012 17:03, Alexandru Petrescu wrote:
> Hello Brian,
> 
> Thank you for the email.  Please see below some comments.
> 
> Le 23/10/2012 14:19, Brian E Carpenter a écrit :
>> I realised while reading this draft that I just don't understand
>> its operating model. It refers to the "requesting" router supplying
>> Prefix Collection and Prefix Information to the delegating router:
>>
>>>     When requesting prefixes a requesting router MUST add for each
>>>     requested prefix a Prefix Information in the Prefix Delegation
>>> option
>>>     of the RS message.
>>
>> However, by definition the requesting router doesn't know what prefix(es)
>> it will be given. So surely all it can ask for is N unspecified prefixes
>> of given lengths?
> 
> Right, this may be wrong.
> 
> I checked the document and it misses, I think, something important. The
> first and most naïve request of a prefix by a Requesting Router should
> have all bits zero and maybe the prefix length 0, or around 64.
> 
> Would this be ok?

Wouldn't the request typically be for a /48 or a /56? If I'm renumbering
an existing network, I will want a prefix that is no longer than what
I already used.

I wonder whether an expensive BMW will always request a shorter prefix
than a Nissan Versa.

>> It also says:
>>
>>>     PC_ID:           An unique identifier of the Prefix Collection.  The
>>>                      PC_ID MUST be unique among all PC_ID known by the
>>>                      requesting router.
>>
>> How can the requesting router provide this in its REQ message? By
>> guessing?
> 
> I think the PC_ID is generated by the requesting router (not by the
> delegating router), just as with IA_ID, no?

Ah yes, I simply misread the text, sorry!

   Brian

> 
>>> 11.  Security Considerations
>>>
>>>     TBD
>>
>> OK, but since a vehicular network is open to any one of millions of
>> unmanaged devices, this will need to be *very* convincing, especially
>> in preventing DOS.
> 
> I agree.  We currently try to understand these threats, and especially
> how they are specific to ND, to prefix delegation and to new flags we add.
> 
> We may add more threat descritpion in the next versions of the draft.
> 
> Alex
> 
>>
>> Regards
>>     Brian Carpenter
>>
>>
>>
> 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to