[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans
As said, question of taste ... Both a prefix aside, or the same prefix are
good choices, and I'm not trying to describe the best practice, but a good
one (or alternatively add the aside prefix description and each reader to
choose).
Regards,
Jordi
> De: "Chip Popoviciu (cpopovic)" <cpopovic@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Wed, 1 Mar 2006 16:39:30 -0500
> Para: "Fred Baker (fred)" <fred@cisco.com>, "Bonness, Olaf"
> <Olaf.Bonness@t-systems.com>
> CC: "Ole Troan (otroan)" <otroan@cisco.com>, <jordi.palet@consulintel.es>,
> <v6ops@ops.ietf.org>
> Conversación: AW: Guidelines for Numbering IPv6 Point-to-Point Links and
> Easing the Addressing Plans
> Asunto: RE: AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing
> the Addressing Plans
>
>
> Along these lines there are two other aspects that are worth
> considering:
>
> 1. A single address with scope larger than link-local would indeed be
> sufficient for a router as long as the network management policies and
> tools do not need to reach specific interfaces for troubleshooting
> purposes for example.
>
> 2. In the case of a Service Provider that offers VPN services, an
> address with a scope larger than link-local is necessary for each VRF
> for things such as PMTU discovery. In that case, it might be easier to
> simply assign that address to the PE-CE link rather than create for
> example a loopback for each VRF.
>
> In principle link-locals are sufficient for the PE-CE link however in
> practice, all little details considered, people might end up assigning
> more than that to the link. And in that sense, it will be better to use
> a prefix set aside by the SP for its own infrastructure rather than what
> is delegated to the customer (as Ole mentioned).
>
> Regards,
> Chip
>
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Fred Baker (fred)
> Sent: Wednesday, March 01, 2006 11:30 AM
> To: Bonness, Olaf
> Cc: Ole Troan (otroan); jordi.palet@consulintel.es; v6ops@ops.ietf.org
> Subject: Re: AW: Guidelines for Numbering IPv6 Point-to-Point Links and
> Easing the Addressing Plans
>
> My assumption as a routing geek is that the only reasonable use of a
> numbered point to point link is to address an end station; it needs an
> address to be useful in the network. But any router/router point-
> to-point interface should be supportable using link-local addresses.
> A router needs one address reachable by its administration (eg non-
> link-local), to be a member of any prefix on a LAN that it is serving,
> and to be able to reach p/p-connected end stations it serves.
>
> On Mar 1, 2006, at 5:41 AM, Bonness, Olaf wrote:
>
>>>
>>> 4. Routing Aggregation of the Point-to-Point Links
>>>
>>> Following this approach and assuming that a shorter prefix is
>>> typically delegated to a customer, in general a /48 [4], it is
>>> possible to simplify the routing aggregation of the point-to-point
>>> links. Towards this, the point-to-point link may be numbered
>>> using
>>> the first /64 of a given /48.
>>>
>>> using the first (or any) subnet of a larger prefix, breaks the
>>> conceptual model of DHCP prefix delegation. the prefix is delegated
>>> to the requesting router and cannot be used to number the link
>>> between the delegating and requesting router.
>>
>> My assumption from a service provider point of view would be to use a
>> dedicated sub-preaefix (e.g. /48)of my own aggregate to address the
>> point-to-point links (e.g. /64) to the custumers (in the case I have
>> to do this).
>>
>> cu
>> Olaf
>
**********************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.