Re: [MBONED] Adam Roach's No Objection on draft-ietf-mboned-driad-amt-discovery-10: (with COMMENT)

["Holland, Jake" <[e-mail]>]

Hi Adam,

Thanks for the review.  Some comments below.

On 2019-12-17, 22:51, "Adam Roach via Datatracker" <[e-mail]> wrote:

> Please expand "AMT" in the title.

[JH] Good catch, thanks.
OLD:
                      DNS Reverse IP AMT Discovery

NEW:
      DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery


---------------------------------------------------------------------------

§2.2:

>                        Figure 2: DRIAD Messaging
>
> This example uses IPv4 rather than IPv6. Please either add a similar diagram
> showing IPv6 usage, or change this diagram to use IPv6. See
> https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further information.

[JH] The point is well taken, thanks.

I have no objection to changing the AMT Relay address in the diagram from
203.0.113.15 to an IPv6 example address, like so:

NEW:
   \  /          +---------------+
    \/           |   AMT Relay   |
                 |  2001:db8::f  |
                 +---------------+
                         |        4: Gateway connects to Relay,
                                     sends Join(S,G) over tunnel
                         |
                Unicast
                 Tunnel  |

     ^                   |        3: --> DNS Query: type=AMTRELAY,
     |                           /         15.100.51.198.in-addr.arpa.
     |                   |      /    <-- Response:
 Join/Leave       +-------------+          AMTRELAY=2001:db8::f
  Signals         | AMT gateway |


However, the full application of this suggestion introduces an unfortunate
formatting challenge for changing the (S,G) to use IPv6, namely that the
reverse DNS name for e.g. 2001:db8:c::f would become this:

f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

This domain name does not even legally fit into a single line.  In text
I guess I would follow the example from section 2.5 of RFC 3596 and wrap
the "arpa." to the next line:
https://tools.ietf.org/html/rfc3596#section-2.5

But no sane way to fit it into the diagram has occurred to me yet.  If you
have a suggestion that doesn't lose clarity I'd be happy to use it instead,
but I was wondering whether it would be reasonable to just add a paragraph
to the end of section 2.2 providing the substitutions if using IPv6?  I'm
hoping this would do the same job:

NEW:
   In the case of an IPv6 (S,G), the only difference in the AMT relay
   discovery process is the use of the ip6.arpa reverse IP domain name,
   as described in Section 2.5 of [RFC3596]), instead of the in-
   addr.arpa domain name.

   For example, if the (S,G) is (2001:db8:c::f, ffe3::80fc:2), the
   reverse domain name for the AMTRELAY query would be:

   f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.0.0.0.8.b.d.0.1.0.0.2.ip6.
                                                                  arpa.


I agree it's useful to give an example like this, in that it gives
implementors and operators something pasteable to compare against.  But
absent a proposed edit to the diagram that's still reasonable-looking and
correct, would these edits adequately addresses your concerns?

---------------------------------------------------------------------------

§2.6:

>  AMTRELAY records MAY also appear in other
>  zones...

> What would this mean? Is this intended for future specifications to
> take advantage, or is the document assuming that the reader is able
> to figure out the semantics of AMTRELAY RRs elsewhere in the DNS tree?
> If the latter, please spell it out explicitly. If the former, please
> indicate that using records in this way may be specified in future
> documents.

Ah, thanks for noticing this was unclear, I think I didn't explain
this well.

The main point is because the reverse zones are often delegated to a
named zone, and in these cases it's necessary in practice to put the
record in the delegated zone.

Does this make it more clear?

NEW:
   AMTRELAY records MAY also appear in other
   zones, since this may be necessary to perform delegation from the
   reverse zones (see for example Section 5.2 of [RFC2317]), but the use
   case enabled by this document requires a reverse IP mapping for the
   source from an (S,G) in order to be useful to most AMT gateways.

I was intending to leave undefined the use of such records in other
ways.  Do you think it's helpful to add to the end of the above something
like "This document does not define semantics for the use of AMTRELAY
records obtained in a way other than by a reverse IP lookup."?