Subject: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

From: "Brian Haberman" <[email-masked]>
Date: Wed, 30 Sep 2015 06:53:06 -0700

Brian Haberman has entered the following ballot position for
draft-ietf-dnsop-root-loopback-04: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I can't decide if I should ballot Yes because this document does a good
job of describing how to deploy this approach or Abstain because the
fragility introduced in this approach appears to be untenable.

In the meantime, can someone explain why this document is stating a
requirement to deploy this approach with IPv4 only?

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Sep 2015 07:54:45 -0700

Yes. Given that this is running on loopback, it doesn't matter if the 
service is running on either the v4 or v6 loopback address. Unless a 
system running this service has absolutely no v4 at all (it doesn't even 
need to be offering v4 service to customers), the v4 loopback address is 
sufficient.

There seems to be wide disagreement about what is the v6 loopback 
address: some of these addresses exist on some v6 systems but not 
others, or so we were told. If there is a v6 loopback address that is 
universally deployed (as 127/8 is for v4), we can add it, although it 
won't actually make this more deployable.

--Paul Hoffman

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Sep 2015 11:12:48 -0400

Hi Paul,

> won't actually make this more deployable.

I am not sure how much clearer the definition of IPv6 loopback could be
(https://tools.ietf.org/html/rfc4291#section-2.5.3).  Of course, if it
is an implementation issue, there is not much the IETF can do.

Thanks for the quick response.

Regards,
Brian

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Sep 2015 08:18:15 -0700

> Thanks for the quick response.

If the WG agrees that 0:0:0:0:0:0:0:1 is always present, we can 
certainly add that to the document. I now cannot find any on-list 
mention of why this isn't useful in all v6-capable systems, so it might 
have been a hallway conversation.

--Paul Hoffman

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Sep 2015 11:26:16 -0400

Hi Paul,

> have been a hallway conversation.

It seems like the WG can cover both address families by simply making
these changes:

OLD:

   o  The system MUST be able to run an authoritative server on one of
      the IPv4 loopback addresses (that is, an address in the range
      127/8).

NEW:

   o  The system MUST be able to run an authoritative server on one of
      the loopback addresses (that is, an address in the range
      127/8 for IPv4 or ::1 in IPv6).

OLD:

   2.  Start the authoritative server with the root zone on a loopback
       address that is not in use.  This would typically be 127.0.0.1,
       but if that address is in use, any address in 127/8 is
       acceptable.

NEW:

   2.  Start the authoritative server with the root zone on a loopback
       address.  This would typically be 127.0.0.1 in IPv4 or ::1 in
       IPv6.

Why does the document say that the address should not be in use?

Brian

---

From: "John Levine" <[email-masked]>
Date: 30 Sep 2015 16:45:48 -0000

>won't actually make this more deployable.

RFC 4291 says there is one v6 loopback address at ::1.  What other
addresses do people think are loopbacks?

I suppose you could use link local addresses on a loopback
pseudo-interface, to get roughly the same effect but that's not really
the same thing.

One concrete advantage of IPv4 over IPv6 in this context is that any
address in 127/8 is a loopback address so if there's already something
listening on 127.0.0.1 like the local DNS cache, you can put your root
mirror on some other address like 127.0.1.0.  In v6 if your cache is
listening on ::1, you're stuck using a kludge.

R's,
John

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Sep 2015 09:53:49 -0700

> Why does the document say that the address should not be in use?

I'll add the v4/v6 wording to the post-IESG-review draft unless there is 
objection in the WG.

John Levine just answered your question about why the address might 
already be in use, which was something that was brought up in the early 
discussion of this draft in the WG. It means that you can't run both 
this and some other DNS-listening task on ::1, whereas you can run both 
on different addresses in 127/8. We'll cover that in the new wording.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 30 Sep 2015 16:55:36 -0000

>Why does the document say that the address should not be in use?

In many systems a local DNS cache or forwarder listens on 127.0.0.1
and ::1.  That's why the examples in the draft run the root mirror on
127.12.12.12.

I you can tell your cache and mirror server to use nonstandard ports,
you could run the mirror in IPv6 on ::1 on some other port like 5353,
but ugh.

R's,
John

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 30 Sep 2015 12:56:46 -0400

On 30 Sep 2015, at 12:53, Paul Hoffman wrote:

> I'll add the v4/v6 wording to the post-IESG-review draft unless there 
> is objection in the WG.

I like the v4/v6 wording, for what that's worth.

> already be in use, which was something that was brought up in the 
> early discussion of this draft in the WG. It means that you can't run 
> both this and some other DNS-listening task on ::1, whereas you can 
> run both on different addresses in 127/8. We'll cover that in the new 
> wording.

Since a single operator controls both ends, there's no need to use a 
well-known port. If you can't bind to 127.0.0.1:53 because something 
else is already listening there, use 127.0.0.1:12345.

Joe

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 30 Sep 2015 13:41:19 -0400

Joe Abley wrote:
> >discussion of this draft in the WG. It means that you can't run both this
> >and some other DNS-listening task on ::1, whereas you can run both on
> >different addresses in 127/8. We'll cover that in the new wording.
> 
> well-known port. If you can't bind to 127.0.0.1:53 because something else is
> already listening there, use 127.0.0.1:12345.

Hi, Joe:

If I'm not mistaken, this would depend on the support in the recursive
implementation for sending queries to non- well-known ports.  Appendix B
gives an example Unbound configuration which supports this (you append
@<port> to the IP address), but AFAIK the example BIND configuration
only supports querying the "static-stub" servers on the well-known port.

-- 
Robert Edmonds

---

From: Evan Hunt <[email-masked]>
Date: Wed, 30 Sep 2015 18:26:04 +0000

On Wed, Sep 30, 2015 at 01:41:19PM -0400, Robert Edmonds wrote:
> but AFAIK the example BIND configuration

This is true. It's implemented as a virtual delegation, and works the same
as a regular delegation.  NS and glue records don't have a place to put a
port number, so static-stub zones don't allow you to configure one.

It should be easy enough to create a local alias address for the purpose
though.  "ifconfig lo inet6 add ::2 alias", salt to taste.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 01 Oct 2015 08:35:14 +1000

> though.  "ifconfig lo inet6 add ::2 alias", salt to taste.

::2 is a bad idea.  Picking a ULA prefix and using it works.

Named does that when it is running its system tests. fd92:7065:b8e:ffff::1
through fd92:7065:b8e:ffff::8 to be exact.

Mind you ::1 is all that is needed for this anyway and named has
views and can select which view based on things other than port
and/or address.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 1 Oct 2015 01:33:57 -0000

>though.  "ifconfig lo inet6 add ::2 alias", salt to taste.

Uh, no.  The *only* loopback address is ::1.  The rest of 0000::/8 is reserved.

If you have a loopback software interface, you could set up a link
local address like fe80::1, but now your DNS software has to
understand link scoped addresses like fe80::1%lo.

Having set up a DNS cache on my LAN using link local IPv6 addresses, I
can report that it doesn't work very well.

All in all, I think the advice to stick with IPv4 loopback addresses
is reasonable.  We can revisit this in 2050 when IPv4 is starting to
be phased out.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Sep 2015 18:46:35 -0700

> Uh, no.  The *only* loopback address is ::1.  The rest of 0000::/8 is reserved.

right. just like 127.0.0.0/8 is reserved. yet i use 127.0.0.2, .3, and
so on, all the time. i think it's probably safe to intrude on this
"reservation" for this use case.

> can report that it doesn't work very well.

agreed.

> is reasonable.  We can revisit this in 2050 when IPv4 is starting to

disagreed. ipv4 should die a-s-a-p. don't bring up any new ipv4 services
unless you are sure they have to talk to the legacy internet. which is
demonstrably not the case for localhost dns service.

now you don't see it:

root@family:/home/vixie # ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

now you do:

root@family:/home/vixie # ifconfig lo0 inet6 ::2/128 alias
root@family:/home/vixie # ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::2 prefixlen 128
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

ntpd is a grabby little thing:

root@family:/home/vixie # netstat -an | grep ::
tcp6       0      0 ::1.465                *.*                    LISTEN
tcp6       0      0 ::1.587                *.*                    LISTEN
tcp6       0      0 ::1.25                 *.*                    LISTEN
tcp6       0      0 ::1.993                *.*                    LISTEN
tcp6       0      0 ::1.143                *.*                    LISTEN
tcp6       0      0 ::1.995                *.*                    LISTEN
tcp6       0      0 ::1.110                *.*                    LISTEN
udp6       0      0 ::2.123                *.*
udp6       0      0 fe80::1%lo0.123        *.*
udp6       0      0 ::1.123                *.*
udp6       0      0 fe80::2a0:98ff:f.123   *.*

i had to alter these lines of my ipfw configuration:

add     pass    all     from any to any via lo0
add     deny    all     from any to { ::1 or 127.0.0.0/8 }
add     deny    ip      from { ::1 or 127.0.0.0/8 } to any

they now read:

add     pass    all     from any to any via lo0
add     deny    all     from any to { ::1 or ::2 or 127.0.0.0/8 }
add     deny    ip      from { ::1 or ::2 or 127.0.0.0/8 } to any

i had to add a line to ntp.conf:

restrict -6 ::1
restrict -6 ::2

noting, the other lines in that vicinity tell us things about
127.0.0.0/8 that the IETF might not know:

restrict 127.127.1.0

but anyway, it works:

root@family:/home/vixie # ntpq -p ::2
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
 mm1.redbarn.org 108.61.194.85    3 u    1   64    1    0.287    3.617  
0.075
 ks.redbarn.org  208.75.88.4      3 u    2   64    1    1.171   -0.744  
0.000

-- 
Paul Vixie

---

From: joel jaeggli <[email-masked]>
Date: Wed, 30 Sep 2015 19:01:11 -0700

> "reservation" for this use case.

127.0.0.0/8 is in fact entirely reserved for loopbacks rfc 990 (class a
was great even if I don't remember it that well)

::1/128 is the rfc 4291 loopback

that doesn't mean we can't address that but:

1.  ::2 isn't infact reserved for that purpose

2. 4291 deprecated ip4 compatible v6 addresses and declared that space
unusuable which makes anything in ::/96  a bad example.

    The "IPv4-Compatible IPv6 address" is deprecated by this document.
   The IANA should continue to list the address block containing these
   addresses at http://www.iana.org/assignments/ipv6-address-space as
   "Reserved by IETF" and not reassign it for any other purpose.  For
   example:

      0000::/8        Reserved by IETF        [RFC3513]      [1]

   The IANA has added the following note and link to this address block.

      [5]  0000::/96 was previously defined as the "IPv4-Compatible IPv6
           address" prefix.  This definition has been deprecated by RFC
           4291.

   The IANA has updated the references for the IPv6 Address Architecture
   in the IANA registries accordingly.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 1 Oct 2015 02:42:57 +0000

> Uh, no.  The *only* loopback address is ::1.  The rest of 0000::/8 is reserved.

Anything is a loopback address if you alias it on your loopback interface.

::2 was only intended as an example (that's why I said "salt to taste"),
but it was not a particularly well-chosen one.

I mean, I'd happily use it on my own system, as I'm reasonably confident
there'll never be a real ::2 address for it to collide with, but for
describing the mechanism in an RFC we should use something in the address
space reserved for documentation, so let's say 2001:db8::1.