Subject: [mif] Domain name issue in draft-stenberg-mif-mpvd-dns

From: Ray Bellis <[email-masked]>
Date: Tue, 15 Mar 2016 10:26:37 +0000

Looking at section 3 of this draft, I have a problem with the
specification where it says that for e.g. a /64 the DNS lookup should be
for _pvd.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x....ip6.arpa, and likewise the
/80 example (with 12 leading zeros).

Taking the /80 example, it would be impossible given this specification
to distinguish between a /80 where the bits between 64 and 80 were all
zeros and the corresponding /64 - they would both end up at the same
point in the ip6.arpa hierarchy.

In my opinion (and I do have some prior art in this space, see RFC 7216)
the "_pvd" label must be at the point in the ip6.arpa that presents the
same level as the prefix being queried for.  Any leading zeros below
that point (i.e. to the left in the domain name) MUST be omitted.

Hence in the /80 case, it would be _pvd.<20 labels>.ip6.arpa and in the
/64 case it would be _pvd.<16 labels>.ip6.arpa

Ray

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Mar 2016 13:08:55 +0200

> On 15.3.2016, at 12.26, Ray Bellis <[email-masked]> wrote:

Actually we considered it a feature and not a bug, i.e. subdelegation would still result in same PVD available. I am not sure your scheme would work with subdelegation though.

Given broad example, ISP has /40 for home users, but ultimately the prefix in use may be e.g. /64 (or even something more narrow). Having the _pvd.* in 'all' prefix lengths would be obviously available, or performing (up to 128) lookups with subsequently shorter/longer prefix lengths.

I am not sure how client would know to start lookups from /40, or from /56 assigned to a home, if the link has /64.

Cheers,

-Markus

---

From: Ray Bellis <[email-masked]>
Date: Tue, 15 Mar 2016 11:22:08 +0000

On 15/03/2016 11:08, Markus Stenberg wrote:
> Actually we considered it a feature and not a bug, i.e. subdelegation
> would still result in same PVD available. I am not sure your scheme
> would work with subdelegation though.

OK, I see that, but I still think you have a problem since:

   2001:0:0:0::/64

and

   2001:0:0:0:0::/80

and even:

   2001::/16

will end up at the same domain name.

> Given broad example, ISP has /40 for home users, but ultimately the
> prefix in use may be e.g. /64 (or even something more narrow). Having
> the _pvd.* in 'all' prefix lengths would be obviously available, or
> performing (up to 128) lookups with subsequently shorter/longer
> prefix lengths.
> 
> I am not sure how client would know to start lookups from /40, or
> from /56 assigned to a home, if the link has /64.

In RFC 7216 we took a "minimal" tree climbing approach, putting the
records at "common" LIR / RIR prefix boundaries of /64, /56, /48, or
/32.   Anything more would have angered the DNS Gods...

Is there no other way for the client to learn the size of the upstream
PD from which its /64 has been carved out?

Ray

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Mar 2016 13:35:45 +0200

> On 15.3.2016, at 13.22, Ray Bellis <[email-masked]> wrote:

Not necessarily. Your home _could_ provide (split horizon) different records than someone else's home. Or ISP could subdelegate that part to your home (then again, I am not sure I would bet on it).

> PD from which its /64 has been carved out?

Not without some new option in RA/DHCP I think.

Cheers,

-Markus

---

From: Margaret Cullen <[email-masked]>
Date: Tue, 15 Mar 2016 14:44:02 -0400

Personally, I think the lookup should be via PVD name, not based on the IP address of the link, as there are many cases in which the IP addresses known to the end nodes are not known to the DNS.

Margaret

On Mar 15, 2016, at 6:26 AM, Ray Bellis <[email-masked]> wrote:

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif