Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded

From: Jen Linkova <[email-masked]>
Date: Tue, 2 Oct 2018 13:13:02 +1000

Hi Nick,

Thanks a lot for your comments - sorry for delayed response..

On Fri, Jul 27, 2018 at 7:15 PM <[email-masked]> wrote:
> This is valuable, thank you.
> Where is it best to capture "Implementation considerations"; something like section 6 of https://tools.ietf.org/html/rfc8106

To be honest I'm not sure it should be in this draft.
I might be wrong but as long as the document describes the host
behavior, we shouldn't be prescribing how exactly such behavior is
implemented.

> IMHO it would be beneficial to capture these aspects:
> -Pref64 "Repository management"

See my comment above.

> -Handling multiple pref64 from different sources
> -Handling RA updates on multiple interfaces
>
> There are security implications of having multiple pref64 sources, would that be in this paper?
> Multihoming needs some consideration. Regarding the CLAT or other user function of the pref64, will the function be of global scope or would multiple functions be in play e.g. per interface.

Good point.
We've just submitted  -02 version
https://datatracker.ietf.org/doc/draft-pref64folks-6man-ra-pref64/

which has a section discussing multiple prefixes from same or
different sources as well as multihoming.

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Jen Linkova
> Sent: 20 July 2018 16:26
> To: V6 Ops List <[email-masked]>; Mohamed Boucadair <[email-masked]>
> Subject: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded
>
> Hello,
>
> As it's been mentioned at the mic, the -01 version of
> draft-pref64folks-6man-ra-pref64
>
> https://datatracker.ietf.org/doc/html/draft-pref64folks-6man-ra-pref64
>
> Feedback is appreciated.
>
> In particular, Mohamed, may I ask you to review the new text and let us know if it addresses your concerns? Thanks!
>
> --
> SY, Jen Linkova aka Furry
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

-- 
SY, Jen Linkova aka Furry

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 2 Oct 2018 12:30:53 +0900

On Tue, Oct 2, 2018 at 12:13 PM Jen Linkova <[email-masked]> wrote:

> > Where is it best to capture "Implementation considerations"; something
> like section 6 of https://tools.ietf.org/html/rfc8106
>

As a host implementer and an author, I think it's actually not a good idea
to specify the implementation in the RFC that defines an option. There are
many cases in the IPv6 specifications where the lack of implementation
experience meant that some of the details of the protocols were
overspecified and required an RFC update to fix.

The one that happens to come to mind at the moment is RFC 7048, which was
required only because NUD probing strategy was too strictly specified in
RFC 4861. But RFC 8106 itself is another example: because it doesn't allow
for any sort of multi-PVD operation, its guidance on a multi-PVD host (like
pretty much any mobile OS today) is at best confusing and at worst
incorrect. RFC 8106 regularly refers to "the resolver repository" as if
there were only one of them, but a multi-PVD host cannot have only one
resolver repository. So I'd expect that the popular implementations of RFC
8106 (at least the ones on mobile nodes) all actually violate the letter of
the implementation considerations.

Instead of writing implementation considerations, we should focus on
observed behaviour. The version we just uploaded contains some text on that
already; please look at it and see if you think there are things that it
should clarify or further specify.

---

From: <[email-masked]>
Date: Tue, 2 Oct 2018 07:04:57 +0000

I will take a look thanks, and i agree with you; When you call out 'observed behavior' i think that better describes what i am looking for in general on the points i made.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Lorenzo Colitti <[email-masked]>
Sent: Tuesday, October 2, 2018 4:30:53 AM
To: Jen Linkova
Cc: Heatley,N,Nick,TQB R; [email-masked] WG
Subject: Re: [v6ops] draft-pref64folks-6man-ra-pref64-01 uploaded

As a host implementer and an author, I think it's actually not a good idea to specify the implementation in the RFC that defines an option. There are many cases in the IPv6 specifications where the lack of implementation experience meant that some of the details of the protocols were overspecified and required an RFC update to fix.

The one that happens to come to mind at the moment is RFC 7048, which was required only because NUD probing strategy was too strictly specified in RFC 4861. But RFC 8106 itself is another example: because it doesn't allow for any sort of multi-PVD operation, its guidance on a multi-PVD host (like pretty much any mobile OS today) is at best confusing and at worst incorrect. RFC 8106 regularly refers to "the resolver repository" as if there were only one of them, but a multi-PVD host cannot have only one resolver repository. So I'd expect that the popular implementations of RFC 8106 (at least the ones on mobile nodes) all actually violate the letter of the implementation considerations.

Instead of writing implementation considerations, we should focus on observed behaviour. The version we just uploaded contains some text on that already; please look at it and see if you think there are things that it should clarify or further specify.