Re: [MEXT] Issue #4 Remove references to site-local addresses [George Tsirtsis <tsirtsis at googlemail.com>]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEXT] Issue #4 Remove references to site-local addresses [George Tsirtsis <tsirtsis at googlemail.com>]



Ah never mind, I just realised that the bulk of the text is what I
originaly proposed.

Sorry about that.
Thanks
George



On 6/28/08, George Tsirtsis <tsirtsis at googlemail.com> wrote:
> I am on vacation so I can not check your text right now, but I
> proposed text for this when I brought up the issue, a long time ago.
> Was anything wrong with it?
>
> Thanks
> George
>
>
>
>
> On 6/28/08, Charles E. Perkins <charles.perkins at earthlink.net> wrote:
>>
>> Hello folks,
>>
>> I've reviewed the discussion about issue #4, and it seems to me that
>> a relatively painless compromise is available.  Namely, we could simply
>> delete the "SHOULD NOT" recommendation regarding the use of
>> ULAs as home or care-of addresses, while maintaining the cautionary
>> note about potential inaccessibility of correspondent nodes.
>>
>> Here is the resultant text, which is otherwise almost identical to
>> George's text except for splitting a run-on sentence into two
>> sentences.
>>
>> ---------------------------------------------------------------------------
>> OLD TEXT:
>> =========
>> 3.1. General Terms
>> ...
>>    unicast routable address
>>
>>       An identifier for a single interface such that a packet sent to it
>>       from another IPv6 subnet is delivered to the interface identified
>>       by that address.  Accordingly, a unicast routable address must
>>       have either a global or site-local scope (but not link-local).
>>
>> NEW TEXT:
>> =========
>> 3.1. General Terms
>> ...
>>    unicast routable address
>>
>>       An identifier for a single interface such that a packet sent to it
>>       from another IPv6 subnet is delivered to the interface identified
>>       by that address.  Accordingly, a unicast routable address must
>>       either be global IPv6 address or a unique local IPv6 address.
>>
>> ---------------------------------------------------------------------------
>>
>> OLD TEXT:
>> =========
>> 4.6. Site-Local Addressability
>>
>>
>>    This specification requires that home and care-of addresses MUST be
>>    unicast routable addresses.  Site-local addresses may be usable on
>>    networks that are not connected to the Internet, but this
>>    specification does not define when such usage is safe and when it is
>>    not.  Mobile nodes may not be aware of which site they are currently
>>    in.  It is hard to prevent accidental attachment to other sites, and
>>    ambiguity of site-local addresses can cause problems if the home and
>>    visited networks use the same addresses.  Therefore, site-local
>>    addresses SHOULD NOT be used as home or care-of addresses.
>>
>> NEW TEXT:
>> =========
>> 4.6. Unique-Local Addressability
>>
>>    This specification requires that home and care-of addresses MUST be
>>    unicast routable addresses.  Unique-local IPv6 unicast addresses
>>    [RFC4193] may be usable on networks that use such non-globaly routable
>>    addresses but this specification does not define when such usage is
>>    safe and when it is not.  Mobile nodes may not be aware of which site
>>    they are currently making it hard to prevent accidental attachment
>>    to other sites, resulting in possible unrechability between the MN
>>    and the HA, when unique-local IPv6 routable addresses are used as
>>    care-of addresses.  CNs outside the MN's own site are unlikely
>>    to be reachable when unique-local IPv6 routable addresses are used
>>    as home addresses. If such addresses are used, however, according
>>    to [RFC4193], they are treated as any other global unicast IPv6
>>    address so, for the remainder of this specification, use of
>>    unique-local IPv6 unicast addresses is not differentiated
>>    from other globally unique IPv6 addresses.
>>
>> ---------------------------------------------------------------------------
>>
>> OLD TEXT:
>> =========
>> 10.4.2. Processing Intercepted Packets
>> ...
>>                                             ... Packets addressed to
>>    the mobile node's site-local address SHOULD NOT be tunneled to the
>>    mobile node by default.
>>
>> NEW TEXT (None: old text removed)
>> =========
>>
>> ---------------------------------------------------------------------------
>>
>> OLD TEXT:
>> =========
>> 11.3.1. Sending Packets While Away from Home
>> ...
>>    o  While not at its home link, the mobile node MUST NOT use the Home
>>       Address destination option when communicating with link-local or
>>       site-local peers, if the scope of the home address is larger than
>>       the scope of the peer's address.
>>
>> NEW TEXT:
>> =========
>> 11.3.1. Sending Packets While Away from Home
>> ...
>>    o  While not at its home link, the mobile node MUST NOT use the Home
>>       Address destination option when communicating with link-local peers.
>>
>> ---------------------------------------------------------------------------
>>
>> OLD TEXT:
>> =========
>> 11.5.4. Returning Home
>> ...
>>                                 ...The mobile node MUST multicast such a
>>    Neighbor Advertisement for each of its home addresses, as defined by
>>    the current on-link prefixes, including its link-local address and
>>    site-local address.
>>
>> NEW TEXT:
>> =========
>> 11.5.4. Returning Home
>> ...
>>                                 ...The mobile node MUST multicast such a
>>    Neighbor Advertisement for each of its home addresses, as defined by
>>    the current on-link prefixes, including its link-local address.
>>
>> ---------------------------------------------------------------------------
>>
>> I recommend accepting the above changes in rfc3775bis-01, and
>> thereby resolving issue #4.
>>
>>
>> Regards,
>> Charlie P.
>>
>>
>>
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.