Subject: [v6ops] New Agenda

From: Fred Baker <[email-masked]>
Date: Mon, 2 Jul 2018 17:03:02 -0700

I have posted an updated agenda at https://datatracker.ietf.org/meeting/102/materials/agenda-102-v6ops-01.

My plan is basically to start from the top of the agenda on Thursday afternoon and proceed as far as time permits. draft-templin-v6ops-pdhost may, as a result, slide forward to Thursday afternoon, and there is an outside chance that we will complete the agenda on that day.

For the record, we have three other drafts that I have seen little or no commentary on, but we could use the available time to discuss if there is interest:

https://tools.ietf.org/html/draft-jaeggli-v6ops-indefensible-nd
  "Indefensible Neighbor Discovery", Joel Jaeggli, 2018-07-02,

https://tools.ietf.org/html/draft-palet-v6ops-p2p-links
  "IPv6 Point-to-Point Links", Jordi Palet, 2018-05-29,

https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis
  "IPv6 Address Assignment to End-Sites", Rosalea Roberts, Jordi Palet,
  2018-06-28

I would need to see supportive email commentary on them.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 2 Jul 2018 18:16:16 -0700

>   "Indefensible Neighbor Discovery", Joel Jaeggli, 2018-07-02,
I'm not super enthused about presenting on this one except maybe to
comment on it's purpose. which may sound oxymoronic, but here goes.

In the v6 addressing architecture sparse /64 subnets expose the
control-plane to potentially costly discovery processes. in rfc6583 we
discussed implementation improvements that might limit the impact of a
dos attempt, these were in no way a panacea. In fact actual
methodologies which network  / service operators use to mitigate the the
exposure in part (externally for example) or entirely (by relying on a
methodology other than neighbor discovery, e.g. routing or
registration). some of these methods require longer prefixes then
traditional subnet lengths to be routed and various proposals to allow
for that more generally in the architecture do exist.

My principle motivation in bring this draft to the table was actually to
point out that  some motivations related to discussion in 6man are not
tied to misguided attempts at provider address consumption optimization.

https://datatracker.ietf.org/doc/draft-carpenter-6man-lap/

the discussion on 6man (SAILing LAPs) is up to about 88 messages and
climbing.

or

https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-03
(disclaimer, I am a co-author)

The fact that there is now an 01 draft is mainly due to feedback from
Mark Smith and Brian Carpenter.

Why v6ops as the target? The document is quite closely related in my
mind to 6583, possibly because I was an author of that one, but also
because the mitigations employing routing, subnet size and link-local
networking are in fact in use today in an operational context (as are
stateful firewalls).

I asked for time at IEPG to discuss the problem the document is
attempting survey more widely. As that (non-ietf) community is largely
operator focused I except what will be discussed there will probably no
be the document itself.

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