Re: [Mip4] Prefix Alloc with DHCPv6-PD? Re: AD review of mip4-dsmipv4
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mip4] Prefix Alloc with DHCPv6-PD? Re: AD review of mip4-dsmipv4
Raj,
Please take a look at the thread starting from Jari's e-mail with
subject: "[Mip4] AD review of mip4-dsmipv4" ...I can forward it to you
offlineif you do not have it (let me know).
George
On Tue, Sep 9, 2008 at 12:14 PM, Basavaraj Patil
<basavaraj.patil at nokia.com> wrote:
>
> Hi George,
>
> Comments inline:
>
>
> On 9/9/08 8:16 AM, "ext George Tsirtsis" <tsirtsis at googlemail.com> wrote:
>
>> Hi Raj,
>>
>> I think the distinction you are trying to make no longer applies.
>>
>> Based on Jari's feedback we are now only going to support IPv6
>> prefixes (no addresses).
>
> Why? Is the link model for IPv6 here being assumed to be a P2P link?
> Why not assign an address? (Maybe I missed the discussion on this topic and
> if so please point to the appropriate email in the archives).
>
>> In that sense the DSMIPv4 MN can now register
>> IPv6 Prefixes of any length it wants to its HAv4, but it can NOT
>> register an IPv6 address.
>
> What prevents the MN from registering an IPv6 HoA with the HAv4? I am
> missing something here.
>
>> Presumably then the DSMIPv4 "owns" these
>> prefixes i.e., it does not share them with anyone else. Also note that
>> here is nothing that prevents DSMIPv4 to be used in combination with
>> NEMOv4.
>
> Well, if you assign the prefix to the MN, it owns it. But why assign a
> prefix and not an address? Agree about the applicabiltty to NEMOv4.
>
>>
>> So, when we are trying to solve the issue of how the MN gets ownership
>> of such IPv6 prefixes, it is clear (to me) that we are talking about
>> IPv4 delegation, rather than allocation.
>
> I guess you meant to say IPv6 prefix delegation above.
> But the fundamental question is : Why is the MN being assigned a prefix
> instead of an IPv6 address (starting to be repetetive here). It is okay to
> assign a prefix and that's not the problem. But I think what you are saying
> here is that with DSMIP4 the MN is assigned a prefix only and not just an
> address. Is it the IPv6 link which is created over the (M)IPv4 tunnel that
> is the problem? Or are you trying to avoid the issues of neighbor
> solicitations etc. that exist if the link is considered as shared?
>
> -Raj
>
>>
>> Am I missing something?
>>
>> Regards
>> George
>>
>>
>>
>> On Mon, Sep 8, 2008 at 5:58 PM, Basavaraj Patil
>> <basavaraj.patil at nokia.com> wrote:
>>>
>>> Hi George,
>>>
>>> The I-D in MEXT proposing PD is applicable to NEMO (mobile routers).
>>> I would expect that this mechanism would als o make sense for Proxy MIP6
>>> where the MAG is assigning prefixes to an MN. However I don't see how this
>>> would be applicable in the case of dsmip4. It would work but the prefix is
>>> being assigned to the MN, i.e not being delegated to an MR or LMA type of
>>> entity.
>>>
>>> -Raj
>>>
>>>
>>> On 9/8/08 8:40 AM, "ext George Tsirtsis" <tsirtsis at googlemail.com> wrote:
>>>
>>>> Folks,
>>>>
>>>> Any response to my question below?
>>>>
>>>> Thanks
>>>> George
>>>>
>>>> On Tue, Sep 2, 2008 at 4:42 AM, George Tsirtsis <tsirtsis at googlemail.com>
>>>> wrote:
>>>>> I have one more question/suggestion as I am in the process of editing
>>>>> the draft to incorporate Jari's earlier comments.
>>>>>
>>>>> Section 4.6. "Dynamic IPv6 Prefix allocation", introduces a mechanism
>>>>> for IPv6 prefix allocation using MIPv4 extension; similar to IPv4 HoA
>>>>> address allocation. In light of the decision made recently in MEXT,
>>>>> however, to do IPv6 Prefix allocation in NEMOv6, using DHCPv6-Prefix
>>>>> Delegation (draft-ietf-mext-nemo-pd-00), should we change this?
>>>>>
>>>>> I think it is the right thing to do. In this case we would only have
>>>>> to indicate that DHCPv6 PD runs over the IPv4 HoA to HA tunnel, and
>>>>> then when the IPv6 prefix is allocated, and assuming explicit mode, it
>>>>> has to be registered via the extensions defined in this spec. I assume
>>>>> that we can point directly to the DHCPv6 PD RFC and we do not need to
>>>>> depend on draft-ietf-mext-nemo-pd.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> George
>>>>>
>>>>> On Tue, Sep 2, 2008 at 8:38 AM, George Tsirtsis <tsirtsis at googlemail.com>
>>>>> wrote:
>>>>>> OK, I received some positive responses and no negative ones. I will
>>>>>> remove support for IPv6 addresses from the spec.
>>>>>>
>>>>>> Thanks
>>>>>> George
>>>>>>
>>>>>> On Fri, Aug 29, 2008 at 6:15 PM, Henrik Levkowetz <henrik at levkowetz.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2008-08-29 11:30 George Tsirtsis said the following:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> I reviewed Jari's comments and I think we need to decide on at least
>>>>>>>> one of these as a group before I can create a new version.
>>>>>>>>
>>>>>>>> The current version of the draft supports both IPv6 Prefixes and IPv6
>>>>>>>> addresses. Jari questions why we need to support addresses and I do
>>>>>>>> not have a good answer for that at the moment. Jari, specifically
>>>>>>>> points out that a number of issues in the document would be simplified
>>>>>>>> if we dropped support for addresses i.e., we would:
>>>>>>>>> - get rid of DAD rules
>>>>>>>>> - get rid of ND proxying
>>>>>>>>> - avoid having to say something about SEND in security considerations
>>>>>>>>> section
>>>>>>>>> - simplify authorization and overlap rules
>>>>>>>>> - not have any multilink subnet-style issues
>>>>>>>>> etc
>>>>>>>>
>>>>>>>> Is the WG in agreement with Jari's proposal to only support IPv6
>>>>>>>> Prefixes in this specification?
>>>>>>>
>>>>>>> Works well for me.
>>>>>>>
>>>>>>>
>>>>>>> Henrik (no hat)
>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Mip4 mailing list: Mip4 at ietf.org
>>>>> Web interface: https://www.ietf.org/mailman/listinfo/mip4
>>>>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html
>>>>> Supplemental site: http://www.mip4.org/
>>>>>
>>>
>>>
>
>
--
Mip4 mailing list: Mip4 at ietf.org
Web interface: https://www.ietf.org/mailman/listinfo/mip4
Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.