Subject: [v6ops] Stephen Farrell's No Objection on draft-ietf-v6ops-host-addr-availability-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 04 May 2016 01:25:12 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-v6ops-host-addr-availability-06: No Objection

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-v6ops-host-addr-availability/

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

(I'm getting a bit outside my area of expertise here, but
since I've been playing about with IPv6 recently and am not
shy about asking silly questions... :-)

- I think you're missing one other reason why people
allocate /128's - in a hosting/VPS environment, the hoster
might want to avoid VPS's that originate spam using many
different source addresses over time so as to attempt to
avoid IP address based (bad) reputation accruing to their
outbound spam. Personally, I think associating such
reputation scores with IPv6 prefixes or addresses is a bit
dodgy, but this is I think something that is done in the
wild, (no idea how frequently) so would be worth a mention.
If you have good arguments as to why such a scheme is a bad
idea, that'd be good to include as well.

- I was a bit surprised to not see any mention here of
ULAs. I've seen one DHCPv6 setup where my laptop was
assigned a ULA with a very long lease in the hope of always
having that connectivity to local systems that aren't all
on the link. But having that plus real global addresses
caused glitches as (I think) my OS (ubuntu) wasn't sure
which of the addresses to use as the source for what.
While I didn't explore what was going on there (I just
zapped the lease:-), do you need to say how to handle cases
where one has both real global and ULAs on an interface? 

- I would have liked if you had said that, other things
being equal, OSes SHOULD prefer to use privacy addresses as
the source address or as a default. Is there a reason to
not say that? (Just wondering, I'm not trying to strongly
argue that you do.)

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 May 2016 13:06:26 +0900

> idea, that'd be good to include as well.

Implementing DoS protection or rate limiting based on /128s is highly
inadvisable because any residential user with a /60 can create 2^68 state
table entries. Some hosting providers and even tunnel broker providers
offer /48s. That said, I think this is out of scope for this draft because
a server is not a general purpose host, and this document only applies to
general purpose hosts.

> where one has both real global and ULAs on an interface?

ULAs are different prefixes so they are covered by this text:

   it is RECOMMENDED that IPv6 network deployments provide
   multiple IPv6 addresses from each prefix to general-purpose hosts

We already have guidance on how applications should work in the presence of
ULAs - it's in RFC 6724. This does appear to work for me - I have a network
that provides both ULA and global, and Ubuntu 14.04 just seems to do the
right thing.

> not say that? (Just wondering, I'm not trying to strongly

While I agree, I think this is out of scope for this document and this
working group. There is a lively debate going on in 6man around the topic
of address stability and privacy, and I think that is the right place for
this topic.

Cheers,
Lorenzo

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 May 2016 16:20:27 +1000

> On Wed, May 4, 2016 at 5:25 PM, Stephen Farrell <[email-masked]>
<snip>
> working group.

I agree it is out of scope for this document.

It is in scope for RFC6724, "Default Address Selection for Internet
Protocol Version 6 (IPv6)", and that is exactly what it says ;-)

" 5.  Changed the default recommendation for Source Address Selection
       Rule 7 to prefer temporary addresses rather than public
       addresses, while providing an administrative override (in
       addition to the application-specific override that was already
       specified).  This change was made because of the increasing
       importance of privacy considerations, as well as the fact that
       widely deployed implementations have preferred temporary
       addresses for many years without major application issues."

Regards,
Mark.