Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

["Templin (US), Fred L" <[e-mail]>]

Hi Naveen,

Naveen] As I mentioned earlier in my mail, DHCPv6 is not a usable solution in my case and across all platforms (might be for others too).  That is reason we see so many drafts were invented by honorable members of the group to bridge the gap in SLAAC itself.

I don’t understand that; there are a number of very good publicly-available DHCPv6
implementations that support prefix delegation today. And, to instrument RS/RA to
perform prefix delegation under a new protocol would require a non-trivial amount
of new code. So, why not just use DHCPv6?

Thanks - Fred

PS Please also do not forget that the idea of using the Nonce as a transaction ID
      vessel came from me.

From: Naveen Kottapalli [mailto:[e-mail]]
Sent: Tuesday, November 20, 2018 10:09 AM
To: Brian E Carpenter <[e-mail]>
Cc: Templin (US), Fred L <[e-mail]>; Ole Troan <[e-mail]>; v6ops list <[e-mail]>; 6man WG <[e-mail]>
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

Hello Brian,

Comments inline.

Yours,
Naveen.


On Mon, 19 Nov 2018 at 01:04, Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
On 2018-11-19 06:53, Naveen Kottapalli wrote:
> Hello Brian,
>
> Please find comments inline.
>
> Thanks & Regards,
> Naveen
>
>
> On Sun, 18 Nov 2018, 01:16 Brian E Carpenter <[e-mail]<mailto:[e-mail]>
> wrote:
>
>> On 2018-11-18 06:40, Naveen Kottapalli wrote:
>>> Hello Brian,
>>>
>>> Whether it's a prefix delegation or allocation, it's a resource
>> allocation
>>> from both the host / CPE or a router perspective. Do you see that missing
>>> transaction ID in RS/RA as a mandatory requirement for SLAAC to function
>>> even with proposed protocol?
>>
>> Yes. Without a transaction ID, a nonce, or some equivalent mecahnism
>> there is no way to correlate the request and response unambiguously.
>> In particular your proposal doesn't distinguish between an unsolicited
>> unicast RA announcing a prefix and a solicited unicast RA assigning a
>> prefix, which are totally different actions.
>>
>
> Naveen] Am not yet clear on why we should distinguish between unsolicited
> and solicited RA.  Do we need to distinguish like that?  As per my current
> knowledge any prefix will be allocated or assigned only when RS is received
> from node and didn't come across an use case of a router assigning the
> prefix unsolicited.

Today, no prefixes are assigned on receipt of RS, so I don't understand
your argument. Prefixes are assigned either by configuration or
by DHCPv6-ND.
Naveen] I would see this as partially true.  As one of the forum member mentioned, RA does more than advertising the prefix.  Even in our gateway too prefixes are assigned to subscribers when a RS is received from devices directly tunneled over GRE.  Consider the case of described in RFC8273, where the prefixes are assigned to devices upon receipt of RS.  So, it needn't always be a configuration or DHCPv6 for the prefix allocation or assignment.

> So, since both node and router will have context of
> prefix assigned, we can reserve constant numbers like 0 or 0xFFFFFFFF for
> nonces included in unsolicited RA. I can add a text saying the use of this
> in next version of draft.

But there is no field in an RA for a nonce.
Naveen] That is what my draft is proposing.

>>
>> Handing out resources with a single message exchange is bad practice
>> anyway; if the response is lost, the resource is lost for ever. You really
>> need some kind of two-phase commit.
>
>
> Naveen] Do we really need this? There are equal amount of chances of losing
> a RA or DHCPv6 Avertise / Reply.  A two way commit will induce more delay
> in the resource allocation procedure and it might not be required as the
> retry mechanism is in place.

A retry mechanism is not safe. It might lead to the same prefix being
allocated twice due to lost messages or a race condition. I suggest
that you read up on two-phase commit, which requires a minimum of
four messages.
Naveen] Agree that a two-phase commit is considerably safe.  This can be a subject of future study.

> I would rather say that the resource is never
> lost.  That is because, from router perspective the resource is allocated
> even if the message doesn't reach the solicited node.  A device will anyway
> retry and a router will always sends a response with the same allocated
> prefix.

But it never knows if the response was received, which is a requirement
for safe resource allocation.

>
> The standard RA doesn't have this
>> problem because it's an *announcement* not an *assignment*, and it is
>> repeated at a reasonable frequency, so a lost message doesn't matter.
>>
>
> Naveen] I don't see a difference between the two in my draft. So, didn't
> want to distinguish between the two i.e. standard and the one proposed in
> this draft.  What kind of difference do you see?

As described above. An existing RA says "I route this prefix".
Your RA says "You can use this prefix." That is an utterly different
statement.
Naveen] As mentioned in above example, not all routers might not be eligible to say that "You can use this prefix" (for example, whoever didn't go for a < /64 prefix allocation).  There must not be a big change in existing behavior.  Can you please help me understand your comment?

>> (A device ID, as also used in DHCPv6, doesn't seem to be essential
>> in the same way, but would be needed if an authorisation or
>> logging mechanism is needed, i.e. to answer "Is it OK to give a /56
>> prefix to this box?" or "Which box got that prefix?" you need an
>> identifier for the box.)
>>
> Naveen] This is mentioned in my draft about whether the routers
> configuration allows /56 prefix allocation or not. If not, a router can log
> using the mac address of the device.  We too do the same thing in our
> router.

/56 is only an example of course. Any length prefix could be requested.
Yes, if you trust the MAC address you could use that as an ID. But
if you use DHCPv6 that problem is already solved.
Naveen] As I mentioned earlier in my mail, DHCPv6 is not a usable solution in my case and across all platforms (might be for others too).  That is reason we see so many drafts were invented by honorable members of the group to bridge the gap in SLAAC itself.

    Brian

>
>>
>>>
>>> Also am not sure if am wrong in quoting that *delegation* is the term
>>> coined to mimic SLAAC behavior of prefix allocation from a sub pool.
>>
>> "Delegation", "allocation" or "assignment" are all fundamentally the
>> same, and are all different from the simple announcement function of a
>> normal RA. Your proposal changes an announcement protocol into a
>> management protocol. That's the thing that Ole is asking you to justify.
>> Why do that?
>>
>>     Brian
>>
>>>
>>> Please correct me if am wrong.
>>>
>>> Thanks & Regards,
>>> Naveen
>>>
>>> On Fri, 16 Nov 2018, 01:07 Brian E Carpenter <
>> [e-mail]<mailto:[e-mail]>
>>> wrote:
>>>
>>>> On 2018-11-16 06:43, Templin (US), Fred L wrote:
>>>>> Naveen,
>>>>>
>>>>> The idea of including a DHCPv6 message option in IPv6 ND RS/RA messages
>>>> requires
>>>>> a *new option* to go along with an already existing protocol (namely,
>>>> DHCPv6).
>>>>> The idea your draft builds on uses an existing IPv6 ND option but
>>>> requires a
>>>>> *new protocol* that is not fully specified in your draft yet. My
>> feeling
>>>> is that once
>>>>> the new protocol is fully fleshed out it would look very much like
>>>> DHCPv6, and
>>>>> some people have said that they do not want new protocols.
>>>>>
>>>>> I am actually beyond the point of caring whether the protocol should be
>>>> DHCPv6,
>>>>> but do we also need a new non-DHCPv6 protocol that looks a lot like
>>>> DHCPv6?
>>>>
>>>> I realised when looking at this draft that DHCPv6 has one property that
>>>> RS/RA completely lacks: a transaction ID. I don't see how we can build
>>>> any kind of resource allocation mechanism without some form of
>>>> transactional
>>>> integrity. Prefix delegation is of course a form of resource allocation.
>>>> So that is a fundamental difference between DHCPv6 and RS/RA.
>>>>
>>>>    Brian
>>>>
>>>>>
>>>>> Thanks - Fred
>>>>>
>>>>> From: Naveen Kottapalli [mailto:[e-mail]<mailto:[e-mail]>]
>>>>> Sent: Thursday, November 15, 2018 9:18 AM
>>>>> To: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>
>>>>> Cc: Templin (US), Fred L <[e-mail]<mailto:[e-mail]>>;
>>>> [e-mail]<mailto:[e-mail]>; v6ops list <[e-mail]<mailto:[e-mail]>>; 6man WG <
>> [e-mail]<mailto:[e-mail]>>
>>>>> Subject: Re: [v6ops] New Version Notification for
>>>> draft-naveen-slaac-prefix-management-00.txt
>>>>>
>>>>> Hello all,
>>>>>
>>>>> To be honest, there is no intention to compete with other existing
>>>> protocols.  I see that SLAAC has got some gaps w.r.t the functionality
>> and
>>>> the same is covered in the draft.  And I see the cases where this draft
>>>> solves real time problems where the existing bridge itself is not
>> usable.
>>>>>
>>>>> @Ole / @Fred / others: If a device soliciting something from the router
>>>> using RS is considered as intruding into other territory, IMHO it's very
>>>> unfair way of evaluating.  For that matter whether a PIO is included in
>> RS
>>>> or not, a device is soliciting the information from router.  When this
>>>> draft solves the problems it cannot be put down just by saying it as a
>>>> redundant to another standard, while actually it is not.
>>>>>
>>>>> If a device soliciting required information using the existing protocol
>>>> standards without new message types or option types or flags itself is
>>>> treated as a wrapper or redundant for other standards, aren't there
>>>> overlapping options in both SLAAC and DHCPv6 that can be sent to the
>>>> devices?  For that matter what about the complete SLAAC and DHCPv6?  Am
>> I
>>>> wrong in quoting that both DHCPv6 and SLAAC are redundant protocols to
>> each
>>>> other?
>>>>>
>>>>> I also agree that multiple attempts were made by many respected members
>>>> of the forum to bring in similar changes to whatever my current draft
>>>> suggested.  But not sure why they couldn't become standards.  It shows
>> the
>>>> need of devices that are looking for a solution and am sure people keep
>>>> inventing round-about solutions for the same.
>>>>>
>>>>> If someone sees a problem in mentioning DHCPv6 inside the draft, please
>>>> suggest another change for that.
>>>>>
>>>>> I understand that the forum has finite reservations on providing
>>>> extensions to existing protocols.  But I request the forum and WG
>> chairs to
>>>> evaluate this draft fairly and technically.
>>>>>
>>>>> Yours,
>>>>> Naveen.
>>>>>
>>>>>
>>>>> On Wed, 14 Nov 2018 at 03:31, Brian E Carpenter <
>>>> [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>> in line..
>>>>> On 2018-11-14 09:34, Templin (US), Fred L wrote:
>>>>>> Hi Brian,
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Brian E Carpenter [mailto:[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>]
>>>>>>> Sent: Tuesday, November 13, 2018 11:37 AM
>>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>; Ole Troan <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>
>>>>>>> Cc: v6ops list <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>; 6man WG <
>>>> [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>> Subject: Re: [v6ops] New Version Notification for
>>>> draft-naveen-slaac-prefix-management-00.txt
>>>>>>>
>>>>>>> On 2018-11-14 07:52, Templin (US), Fred L wrote:
>>>>>>>> HI Ole,
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Ole Troan [mailto:[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>]
>>>>>>>>> Sent: Tuesday, November 13, 2018 10:36 AM
>>>>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>
>>>>>>>>> Cc: Naveen Kottapalli <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>; 6man WG <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>
>>>> ;
>>>> v6ops list <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>> Subject: Re: [v6ops] New Version Notification for
>>>> draft-naveen-slaac-prefix-management-00.txt
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 13 Nov 2018, at 19:25, Templin (US), Fred L <
>>>> [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Ole,
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Ole Troan [mailto:[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>]
>>>>>>>>>>> Sent: Tuesday, November 13, 2018 9:38 AM
>>>>>>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>
>>>>>>>>>>> Cc: Naveen Kottapalli <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>; 6man WG <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>
>>>> ;
>>>> v6ops list <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>>>> Subject: Re: [v6ops] New Version Notification for
>>>> draft-naveen-slaac-prefix-management-00.txt
>>>>>>>>>>>
>>>>>>>>>>> Fred,
>>>>>>>>>>>
>>>>>>>>>>>> On 13 Nov 2018, at 17:34, Templin (US), Fred L <
>>>> [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Ole,
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Ole Troan [mailto:[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>]
>>>>>>>>>>>>> Sent: Monday, November 12, 2018 11:57 PM
>>>>>>>>>>>>> To: Templin (US), Fred L <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>
>>>>>>>>>>>>> Cc: Naveen Kottapalli <[e-mail]<mailto:[e-mail]><mailto:
>>>> [e-mail]<mailto:[e-mail]>>>; 6man WG <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>
>>>> ;
>>>> v6ops list <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>>>>>> Subject: Re: [v6ops] New Version Notification for
>>>> draft-naveen-slaac-prefix-management-00.txt
>>>>>>>>>>>>>
>>>>>>>>>>>>> Fred,
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I agree to some extent that DHCPv6 is a format on wire.  But
>>>> am sure it would consume more resources at router to
>>>>>>> support
>>>>>>>>>>>>> DHCPv6
>>>>>>>>>>>>>>> as a whole along with SLAAC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Prefix delegation is quite different from SLAAC.
>>>>>>>>>>>>>>> Regardless this is water under the bridge. Since 2003.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So I can understand this comment, the water under the bridge
>>>> refers to the
>>>>>>>>>>>>>> selection of DHCPv6 PD as the protocol for prefix delegation.
>>>> Is that what
>>>>>>>>>>>>>> you were meaning to say?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure.
>>>>>>>>>>>>
>>>>>>>>>>>> OK, so you are saying that DHCPv6 is *the* chosen protocol for
>>>> Prefix Delegation
>>>>>>>>>>>> and there shall be no alternate IPv6 ND-based protocol in
>>>> addition to that. I don't
>>>>>>>>>>>> mind a statement like that, but would the community agree with
>> it?
>>>>>>>>>>>
>>>>>>>>>>> In general we as a community try to avoid providing multiple
>>>> equivalent solutions to the same problem. Sometimes we fail.
>>>>>>>>>>
>>>>>>>>>> But, do you assert that DHCPv6 is the one and only solution?
>>>>>>>>>
>>>>>>>>> I am saying that solving a problem that is already solved is a
>> waste
>>>> of time and resources.
>>>>>>>>> Now if you install could solve a problem where we don’t have a
>>>> satisfactory solution...
>>>>>>>>
>>>>>>>> OK, then I will say it - DHCPv6 is the one and only solution to
>>>> Prefix Delegation
>>>>>>>> *in cases where a dynamic Prefix Delegation protocol is needed*. (I
>>>> add this
>>>>>>>> qualification because 'draft-templin-v6ops-pdhost' lists other
>>>> non-protocol
>>>>>>>> alternatives for a node receiving a prefix delegation.)
>>>>>>>
>>>>>>> I'm not disagreeing that DHCPv6-PD is the current IETF solution, but
>>>> there
>>>>>>> are some subtleties:
>>>>>>>
>>>>>>> 1) Since there are no protocol police, you can't actually stop people
>>>>>>> using some other method of prefix delegation, which would simply
>> appear
>>>>>>> to be an out-of-band or "manual" mechanism as far as the IETF
>> protocols
>>>>>>> are concerned.
>>>>>>
>>>>>> Right, I wanted to be careful in how I worded my message based on our
>>>>>> knowledge of other non-router methods (including anima) which we
>>>>>> captured in 'draft-templin-v6ops-pdhost'. From that document:
>>>>>>
>>>>>> "10.  Prefix Delegation Services
>>>>>>
>>>>>>    Selection of prefix delegation services must be considered
>> according
>>>>>>    to specific use cases.  An example service is that offered by
>> DHCPv6
>>>>>>    [RFC3633].  An alternative service based on IPv6 ND messaging has
>>>>>>    also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit].
>>>>>>
>>>>>>    Other, non-router, mechanisms may exist, such as proprietary IPAMs,
>>>>>>    [I-D.ietf-anima-prefix-management] and
>>>>>>    [I-D.sun-casm-address-pool-management-yang]."
>>>>>>
>>>>>> Does this still ring true, or do we need to make some adjustments
>> based
>>>>>> on these recent discussions?
>>>>>
>>>>> I think it's still true, although as Ole and I said, proposals such as
>>>>> anima-prefix-management, CASM amd HNCP do recognize DHCPv6-PD as the
>>>>> boundary mechanism. On the other hand, naveen-slaac-prefix-management
>>>>> intentionally competes with DHCPv6-PD, which is a different
>> discussiion.
>>>>>
>>>>>     Brian
>>>>>
>>>>>>
>>>>>> Thanks - Fred
>>>>>>
>>>>>>> 2) We did think about this question a bit while developing
>>>>>>> https://tools.ietf.org/html/draft-ietf-anima-prefix-management-07
>>>>>>> (which is approved and in the RFC Editor queue waiting for missing
>>>>>>> references). The appendix A2 is supposed to show how a prefix
>>>>>>> management system would interface to DHCPv6-PD at the edges of an
>>>>>>> autonomic network. I think you'd find something similar in any sort
>>>>>>> of coordinated prefix management scheme.
>>>>>>>
>>>>>>> 3) A similar situation arises in HNCP:
>>>>>>> https://tools.ietf.org/html/rfc7788#section-6.3.4
>>>>>>>
>>>>>>>    Brian
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> The value proposition of something new, has to be different
>> than
>>>> “just different wrapping”.
>>>>>>>>>>>>
>>>>>>>>>>>> By "different wrapping", are you are talking about non-DHCPv6
>>>> protocol proposals?
>>>>>>>>>>>> If not, if you mean to say that the idea of including a DHCPv6
>>>> option in RS/RA messages
>>>>>>>>>>>> is "just a different wrapping", then that is not entirely true.
>>>> By including both the IPv6
>>>>>>>>>>>> ND and DHCPv6 functions in a single message exchange, there are
>>>> fewer messages
>>>>>>>>>>>> and fewer round trips. That in itself is interesting.
>>>>>>>>>>>
>>>>>>>>>>> Don’t really see that as interesting. You will not save a round
>>>> trip, since the two protocols don’t depend on each other.
>>>>>>>>>>
>>>>>>>>>> This gets us back to the M&O bits where there is a
>> cross-dependence
>>>> between the two
>>>>>>>>>> protocols. Historically, you are supposed to wait until the RS/RA
>>>> exchange and check the
>>>>>>>>>> M&O bits before invoking DHCPv6 (two round trips). Are you saying
>>>> that that is no longer
>>>>>>>>>> the case? Have we declared that the M&O bits are deprecated?
>>>>>>>>>
>>>>>>>>> DHCPv6 PD has never had any dependency on the M&O bits. PD is a
>>>> protocol between routers.
>>>>>>>>
>>>>>>>> OK, then let's ignore the M&O bits - I am fine with that.
>>>>>>>>
>>>>>>>>>> It is also important that there are fewer messages - two instead
>> of
>>>> four. That matters
>>>>>>>>>> a great deal on low end links.
>>>>>>>>>
>>>>>>>>> I would like to see the maths behind that.
>>>>>>>>> Use header compression then.
>>>>>>>>
>>>>>>>> It isn't only a question of how many bytes - the question is moreso
>>>> how
>>>>>>>> many channel accesses are necessary. On some links, sending
>>>> everything in
>>>>>>>> a single channel access is less prone to collisions than requiring
>>>> multiple
>>>>>>>> channel accesses.
>>>>>>>>
>>>>>>>> Think about CB radio - after you say "breaker, breaker one-nine" you
>>>> get
>>>>>>>> to say as much as you want (within reason) without having to undergo
>>>>>>>> channel contention multiple times. (That is not to say that common
>>>> data
>>>>>>>> links function the same as CB radio, but they do have their CSMA
>>>> protocols
>>>>>>>> for making sure they don't step on someone else's transmission.)
>>>>>>>>
>>>>>>>>>>> Different wrapping. As in exactly same protocol semantics, just
>>>> options in ND instead of DHCP.
>>>>>>>>>>
>>>>>>>>>> No, the options in RS/RA are exactly DHCPv6 - they are not
>>>> different than DHCPv6.
>>>>>>>>>> That is the whole point.
>>>>>>>>>
>>>>>>>>> Right. I am sorry but I struggle getting why that is valuable. ND
>> is
>>>> also a one to many protocol. That’s not suitable for per-router
>>>>>>>>> delegation.
>>>>>>>>
>>>>>>>> IPv6 ND messages are permitted to be sent as unicast (one-to-one).
>> In
>>>> this
>>>>>>>> case, the presence of a DHCPv6 option in the RS message is
>> indication
>>>> that
>>>>>>>> the RA is to be returned via unicast.
>>>>>>>>
>>>>>>>> Thanks - Fred
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Ole
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks - Fred
>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>> Ole
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks - Fred
>>>>>>>>>>>>
>>>>>>>>>>>>> We are still struggling with “permissionless extensions” of an
>>>> IPv6 network. Something that solved that problem, would be a
>>>>>>> lot
>>>>>>>>>>> more
>>>>>>>>>>>>> interesting to talk about.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Ole
>>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> v6ops mailing list
>>>>>>>> [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>
>>>>
>>>>
>>>
>>
>>
>