re: "this case must work”
There sure is a lot of complexity in this thread to ensure that link local
addresses can be used outside of the local scope.
Some simpler suggestions,
1) a stateful proxy. I know, I know. But how many devices are actually going to
need to perform BRSKI at the same
Eliot Lear wrote:
> On the other hand, maybe it's fundamental, but is relying on LL in this
> architecture to go beyond LL boundaries the right thing to do?
We've already established a way around the concern that made me think
that we needed multiple LL for the proxy,
Sure. Use normal unicast addresses (ULA or other) if available.
Eliot
> On Jul 17, 2017, at 9:39 AM, Toerless Eckert wrote:
>
> Can you propose a stateless proxy model that would not pass the link-local
> addresses on to the registrar and that uses Michaels beloved IPinIP
On the other hand, maybe it's fundamental, but is relying on LL in this
architecture to go beyond LL boundaries the right thing to do?
On 7/17/17 8:34 AM, Michael Richardson wrote:
> Toerless Eckert wrote:
> > I thought i had asked that question already but not sure, and not
Sorry, cathing up late with the thread.
Thanks, Eliot. Thats good information. The MAC address based limited
link-local address space is a problem for devices running a proxy.
Do you have an idea about some class of devices that has the issue
that you describe and that could be proxies ?
I know
Brian E Carpenter wrote:
>> Brian E Carpenter wrote: > OK, I'm
>> getting there. More in line:
>>
>> >> 1) Registrar accepts any Lx1 as local. There is no precedent in v6
>> >> APIs to open such a socket, but this
Hi Brian,
On 7/14/17 12:41 AM, Brian E Carpenter wrote:
>
> That may be true, but for BRSKI as such, the only hard requirement is
> an address that is unique on a given link, which is a requirement anyway.
> IPIP is more of an issue for the node providing the proxy, which is
> hopefully a bit
On 14/07/2017 08:58, Eliot Lear wrote:
> Hi Toerless,
>
>
> On 7/6/17 9:09 AM, Toerless Eckert wrote:
>> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote:
>>> It used to be, but the recommendation today is a pseudo-random
>>> value (RFC7217). In any case it's a software choice.
On 13/07/2017 21:40, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > OK, I'm getting there. More in line:
>
> >> 1) Registrar accepts any Lx1 as local. There is no precedent in v6
> >> APIs to open such a socket, but this actually supported
Brian E Carpenter wrote:
> OK, I'm getting there. More in line:
>> 1) Registrar accepts any Lx1 as local. There is no precedent in v6
>> APIs to open such a socket, but this actually supported on many
>> platforms. It's used for nasty stuff like
Brian E Carpenter wrote:
>> Brian E Carpenter wrote: > Is the
>> following correct?
>>
>> > Topology (ASCII art):
>>
>> Topology is essentially correct. As you point out, RFC7217 is the
>> recommendation
On 12/07/2017 12:44, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > Is the following correct?
>
> > Topology (ASCII art):
>
> Topology is essentially correct.
> As you point out, RFC7217 is the recommendation going forward, so having
> a a big
And for those who aren't on v6ops, the answer is clear:
Although for classical host o/s I'm correct, and the norm is
to have a different link-local address on each interface,
a) this is not required by the IPv6 standards, and
b) on L2/L3 switches from major manfacturers, it is common
that many
On 06/07/2017 15:37, Toerless Eckert wrote:
> On Thu, Jul 06, 2017 at 02:19:23PM +1200, Brian E Carpenter wrote:
>> Hi BRSKI authors,
>
> Can i still answer ?
>
> Inline. I only have an ACP author, WG chair and general bloviator hat
> though...
>
>> Is the following correct?
>>
>> Topology
14 matches
Mail list logo