> See also: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 which has
> been discussed today at the Large Interim Meeting
Minor point about this draft: To me there's a contradiction between
2.1 "These link-local addresses SHOULD be hard-coded to prevent
the change of EUI-64 addresses whe
2 16:44
> To: Ole Trøan
> Cc: Usman Latif; ipv6@ietf.org
> Subject: Re: IPv6 address assignment for strictly point-to-point links and
> Device Loopbacks
>
> Some vendors are permitting the use of the link local interface address to be
> used in next hop routing there for negating
(Hopefully) my last email on this topic:
- Not only has RFC 6164 failed to properly update RFC 5375 with any reasoning
provided for 5375 section(s) B.2.xx
- It has also defied and failed to update RFC 4291 which says (section 2.5.1) -
"For all unicast addresses, except those that start with bin
I'll conclude on the following points:
i. The only guidance that's out there today for device loopbacks (whether
informational or standards track) is 5375 -because 6164 (whether voluntarily or
involuntarily) chose not to provide any considerations for /128 loopbacks
ii. A reader following consi
Usman,
On 27/09/2012 12:43, Usman Latif wrote:
> Hi Joel,
>
> RFC 6164 overriding 3627 seems logical
> However, I am looking more from perspective of 5375
RFC 5375 is an Informational document. You are at liberty to read it or not,
and to make use of it or not.
RFC 6164 is a Standards track doc
Hi Joel,
RFC 6164 overriding 3627 seems logical
However, I am looking more from perspective of 5375
Also If one has to "go read the discussion on 6164" to understand it - this is
itself an indication that 6164 has not done a good job of providing a
conclusive recommendation on use of prefixes w
> Sorry i didn't realize that you own this list - my apologies
> If you really have work to do pls disregard my emails instead of
> responding with meaningless emails that are not helping either of
> us...
IETF IPv6 working grou
Sorry i didn't realize that you own this list - my apologies
If you really have work to do pls disregard my emails instead of responding
with meaningless emails that are not helping either of us...
On 27/09/2012, at 5:10 PM, Randy Bush wrote:
>> If you have links to any previous discussions /
> If you have links to any previous discussions / blogs on this long
> cold pot, pls point me to them so I can convince myself that both 5375
> and 6164 have same recommendations for /127 (and /128)
go read the discussion on 6164
we do not care what you do in your network. we do care that you bl
On Thu, Sep 27, 2012 at 3:10 PM, joel jaeggli wrote:
> On 9/26/12 9:47 PM, Randy Bush wrote:
>
>> There is clearly two set of recommendations over the same addressing
>>> scenario which I am only trying to clarify with the IETF community.
>>>
>> There aren't really. The world moved on from 3627 a
--- On Thu, 27/9/12, Randy Bush wrote:
From: Randy Bush
Subject: Re: IPv6 address assignment for strictly point-to-point links and
Device Loopbacks
To: "Usman Latif"
Cc: "Ole Trøan" , "ipv6@ietf.org"
Received: Thursday, 27 September, 2012, 9:17 AM
On 9/26/12 9:47 PM, Randy Bush wrote:
There is clearly two set of recommendations over the same addressing
scenario which I am only trying to clarify with the IETF community.
There aren't really. The world moved on from 3627 and the scenario
described in 6164 represents both observed reality and
> There is clearly two set of recommendations over the same addressing
> scenario which I am only trying to clarify with the IETF community.
no. but please go do whatever you want in your network and stop trying
to stir a long cold pot
randy
--
nt for strictly point-to-point links and
Device Loopbacks
To: "Usman Latif"
Cc: ipv6@ietf.org
Received: Thursday, 27 September, 2012, 4:52 AM
Hi Usman,
At 17:08 26-09-2012, Usman Latif wrote:
> There is clearly two set of recommendations over the same addressing scenario
> which I
Hi Usman,
At 17:08 26-09-2012, Usman Latif wrote:
There is clearly two set of recommendations over the same addressing
scenario which I am only trying to clarify with the IETF community.
RFC 6164 has recommendations that do not encompass all the
recommendations that were put forward in RFC 5375
Ole Trøan
Subject: Re: IPv6 address assignment for strictly point-to-point links and
Device Loopbacks
To: "Usman Latif"
Cc: "Randy Bush" , "ipv6@ietf.org"
Received: Wednesday, 26 September, 2012, 1:06 PM
> Also its a good idea to encompass recommendations for p2
Some vendors are permitting the use of the link local interface address to be
used in next hop routing there for negating the need to us additional unicast
addresses on P2P links. When using routing protocols of OSPFv3 and BGP, I have
used /128 loopback global unicast and configured advertisemen
> Also its a good idea to encompass recommendations for p2p and loopbacks (and
> for that matter any assignment where prefix length is going beyond /64 into
> smaller subnets) into one standard track because the cautions and potential
> overlap issues that may exist for a /127 would pretty much
> IMO RFC 6164 although being very authoritative and direct about use of /127
> (from the same /64) on each p2p link is not giving us any insight into other
> current (or future) reserved addresses that were explained in more detail in
> RFC 5375 so in doing that RFC 6164 is raising doubts in ou
52 AM, Randy Bush wrote:
perhaps we learned some things over time?
randy
From: Usman Latif
Date: 25 September 2012 11:30:09 AM AEST
To: ipv6@ietf.org
Subject: Re: IPv6 address assignment for strictly point-to-point links and
Device Loopbacks
To summarize the whole discussio
perhaps we learned some things over time?
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--
loopback addressing
Regards
Usman
--- On Sat, 22/9/12, Usman Latif wrote:
From: Usman Latif
Subject: Re: IPv6 address assignment for strictly point-to-point links and
Device Loopbacks
To: "ipv6@ietf.org"
Cc: "Brian E Carpenter"
Received: Saturday, 22 September, 2
Forgot to include IPv6 group email in my last email (below)
Further to that, RFC 6164 states in the same statement that:
"When assigning and using any /127 prefixes, the following considerations
apply. Some addresses have special meanings, in particular addresses
corresponding to reserved anycas
Indeed, and I see a sheer wastage in blocking the entire /64 whose one /127 is
used on p2p links.
There are many deployments that already assign bunch of /64 (or lower) prefixes
per hierarchy and encode bunch of useful info in 72-96 and then assign
thousands of /127s out of each /96 (or encode
On 9/21/12 12:03 AM, Usman Latif wrote:
I suppose bodies like IETF all need to ensure that there are
definitive guidelines around addressing architectures so that future
implementations of procotol stacks and features donot overlap with
bits in the IPv6 address space that could potentially
On 21/09/2012 22:35, Usman Latif wrote:
> Thanks Wes for the feedback.
...
Without this stated clearly there is likely to be some instances where
readers interpret it the wrong way and end up assigning multiple p2p links
with /127 subnets from a single given /64 and end up having
Thanks Wes for the feedback.
Some points I'd like to further comment on:
i. You mentioned that a re-address event is no different from re-masking the
links-
this is true to an extent but I think changing subnet mask would still be
relatively easier to manage than having to re-address all links
On Fri, Sep 21, 2012 at 3:23 PM, George, Wes wrote:
> Responding to a couple of different things below inline with [WEG]
>
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Usman Latif
> >>"If you choose to do this, it is further recommended that you reserve
> the entire
Responding to a couple of different things below inline with [WEG]
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Usman
Latif
>>"If you choose to do this, it is further recommended that you reserve the
>>entire /64 so that - if needed in the future - you can expand this
On Fri, Sep 21, 2012 at 10:16 AM, Usman Latif wrote:
> Thanks for the feedback.
> I just want to confirm something.
>
> You wrote:
> "If you choose to do this, it is further recommended that you reserve the
> entire /64 so that - if needed in the future - you can expand this
> configuration _with
Thanks for the feedback.
I just want to confirm something.
You wrote:
"If you choose to do this, it is further recommended that you reserve the
entire /64 so that - if needed in the future - you can expand this
configuration _without_ a major renumbering event."
This is the essence of what I w
Hi,
I am one of the many Network Engineers/architects that are today on the verge
of assigning IPv6 addressing in their core networks.
There are two points that I would like to open a debate on and really looking
for some substantial reasoning and logic on.
And the points are:
Q1: "What i
32 matches
Mail list logo
