Minutes IETF103: v6ops
minutes-103-v6ops-00

IPv6 Operations - IETF 103    Monday November 5, 9:00-11:00

Chairs:
    Fred Baker, Ron Bonica Notes: Barbara Stark, Max Stucchi Jabber:
    Eric Vyncke

Chair discussion Collecting opinions on the weekly "what do you
think about draft-*-nn.txt" threads? Are they useful? Do you want
us to continue them?  CERNET2 IPv6-only Practice: Backbone, Servers,
Clients and 4aaS (Xing Li, Congxiao Bao) NAT64/464XLAT Deployment
Guidelines in Operator and Enterprise Networks (2018-10-10 ,
<draft-ietf-v6ops-nat64-deployment>) IPv6-Ready DNS/DNSSSEC
Infrastructure (2018-10-10, <draft-bp-v6ops-ipv6-ready-dns-dnssec>)
IPv6 Address Assignment to End-Sites (2018-10-09,
<draft-palet-v6ops-rfc6177-bis>) Pros and Cons of IPv6 Transition
Technologies for IPv4aaS (2018-10-06,
<draft-lmhp-v6ops-transition-comparison>) Any other Business  if
there is time, we will take volunteers from the floor

Draft Status
 The status of v6ops drafts, both working group drafts (draft-ietf-v6ops-*)
 and individual submissions to the working group (draft-<author>-v6ops-*),
 may be determined from https://datatracker.ietf.org/wg/v6ops/.

Minutes

################## Chair discussion ################## No bashing
of the agenda.

There were no objections on running the process of adopting and
discussing drafts as done since the last IETF meeting.

draft-templin-v6ops-pdhost was not accepted as a wg item.

################## CERNET2 IPv6-only Practice: Backbone, Servers,
Clients and 4aaS Xing Li, Congxiao Bao ##################

Xing Li presented slides.

On Slide 12 Fred Baker: Channeling Jordi (since this is a question
he likes to ask), what do you mean by IPv6-only?  Jordi Palet
Martinez: To further explain, we need to understand specifically
which part of the network is only IPv6. Because parts of the E2E
path may still have IPv4.  Xing Li: Yes, we need to be more specific.
We consider the LAN in this case.

Bob Hinden: In 6man we're working on an IPv6-only flag in RAs.
Could this work be useful for you ?  Xing Li: Yes.

At end: Nathalie Trenaman asked about the prefix used for CERNET
(2001:0a00::/29), which is very close to the documentation prefix,
asking if they ever had any issue with it.  Xing Li: Not many issues

Lorenzo Colitti asked about the discovery of the NAT64 prefix, and
asked specifically about the prefix size used, if they had any
issues with anything other than /96 Xing: If we want to use MAP-T
then maybe we could do something different.

Colitti: Right now, then you can only do /96.  I'm asking because
we're discussing in 6man on deprecating anything else.  Xing: I
can't see a reason for not being able to use anything different.

Lorenzo: The reason is that it would make the option we're discussing
on adding to RAs more complicated Lorenzo:  Did you verify that iOS
does not support anything different from /96 ?  Xing: We noticed.
It does not.

Fred: Are you still using the same mechanism you were using some
time ago where you needed to have the IPv4 address embedded in your
address ?  This means that you're not using a /96 Xing: Yes, not
using /96. Using /48. This is because of using IPv4 /24.  Fred: An
additional comment (directed to Lorenzo) is they use routing based
on parts of the IPv4 address.  Xing: At some point we move all IPv4
addresses into IPv6 and turn off IPv4.

There were no more questions nor comments.

################## NAT64/464XLAT Deployment Guidelines in Operator
and Enterprise Networks 2018-10-10 , <draft-ietf-v6ops-nat64-deployment>
##################

Jordi Palet presented the slides

Jen Linkova:  In many cases you could just combine the scenarios
and simplify the document.  As it is, the document is a bit too
long.  NIC.cz recently did some measurements on NAT64 and DNS64,
so that can also help.  Jordi:  I had fewer scenarios at the
beginning, but I was told to be more specific.  Graphics make the
document longer and can help understand it.  I don't see the reason
for making the document shorter.  Jen: OK so probably again. I was
under the impression that was the same scenario. Maybe I was just
being lazy and didn't read completely.  Jordi:  I can take a look
again and try to squeeze the text.  We have different views, and I
even was suggested to add more scenarios.  Fred: Jen, are you still
going to do a review of the document ?  Jen: Yes

Warren Kumari:  Stuart Cheshire  noticed that the ipv4only.arpa
name was never added to the registry and he has a document to do
that.  dnsops is not interested, so this group might be more
appropriate.  Jordi:  I mention this in my document, and in the
IANA considerations we need to explicitly state it

Fred:  We need to wait for Jen's review, so for the moment I'll ask
for people to comment on the document.

Jordi:  I would be happy to set up some time this friday to discuss
this.

There were no more comments nor questions.

################## IPv6-Ready DNS/DNSSSEC Infrastructure 2018-10-10
, <draft-bp-v6ops-ipv6-ready-dns-dnssec> ##################

Jordi Palet presented the slides.

Fred: Are you asking ICANN to take a regulatory position ?  Jordi:
These words are in a contract.  I think it should be enforced.

Dan York: That only applies to new TLDs and not to country code
TLDs. The contract is affecting all that it can.  Warren: <not quite
at mic> confirms Jordi:  I know it does not affect all CCTLDs Dan
York:  Have you brought this issue up to dnsops?  Jordi:  I did,
but I didn't get any input.  Dan York: I think it would be helpful.
Dan York:  I agree with the call, but I wouldn't sign any DNS64
records.  Jordi:  You shouldn't have AAAA Records if you don't have
good IPv6 connectivity.

Mark Andrews: You're making an assumption that if you can do DNSSEC
you can also do IPv6.  This is not true for many TLDs.  For DNSSEC
you only need a DNS Server that supports it.  For IPv6 you need
more infrastructure.  Anything that slows down DNSSEC deployment
tying it down to IPv6 is a bad idea.  Jordi:  Are you suggesting
we only stick to a recommendation without asking ICANN/IANA to fix
it ?

Mark:  There are these operators who have contracts and already do
IPv6.

Paul Wilson: Operators know there's lack of support.  Registrars
should support IPv6 records/glues/other.  I'm not sure there's
consensus on wether the contract is right or not, but I'm not even
sure there's monitoring being done on how that is enforced.  Jordi:
IANA/ICANN should work with the liaison on what to do regarding
this document.

Jen Linkova: Operators do not really understand the impact of
deploying DNSSEC. Draft is currently saying we should get DNSSEC
in 18 months and I don't think that's feasible. We should not be
trying to enforce this. There are countries that have no IPv6 at
all.  Jordi: Ok.

Dan York:  I think you're off on the idea that someone with DNSSEC
Expertise, can also do IPv6.  DNSSEC is easier than IPv6 to enable
as it requires less work (transit, firewalls, other).  Please, don't
make that assumption in the document. And as for organization to
go to: IANA maybe but not ICANN.  Jordi: Thank you.

Fred: IANA is a service function, not an executive function.  I
think you need to change the draft to make it a recommendation, and
then we need input from dnsops.  Jordi:  I'll try to ask dnsops to
read the document and provide input.  We should work with the ICANN
liaison to see if they have any input and see if something could
be done.

Fred:  Feel free to talk to the liaison.

Fred:  I have another question.  During the discussion on Cameron's
document (draft-bp-v6ops-ipv6-ready-dns-dnssec-00) people suggested
it should go as a BCP.  Do we think that's the direction we should
go ?

No Hums for the document becoming a BCP.

There were no more questions nor comments.

################## IPv6 Address Assignment to End-Sites 2018-10-09
, <draft-palet-v6ops-rfc6177-bis> ##################

Jordi Palet presented the slides.

Joel Jaeggli:  That is a curious case.  We can be certain that the
assumptions you're making there in the slides are wrong.  I think
we're some orders of magnitude off.  Ron :  I think this slide is
more for human rather than for computers.  Jordi:  I'm not trying
to be accurate here.

Geoff Huston:  The  whole idea of IPv6 was not to put pressure on
operators to give more space.  The idea was to provide operators
with enough addresses.  The case you're trying to make - that /48s
are fine for everyone - is irresponsible.  Let's try not to repeat
the same pressure we put on operators with IPv4, and let's learn
from our mistakes.  It does not cut it for me.

Christian Huitema:  I kind of agree with what you said.  The pressure
is not linked to the ratio we're using.  We explain it in RFC3194.
Go from there and look at the logarithmic effect there.

Barbara Stark: I disagree, on various levels.  You mention mobile
networks handing out /64s, which is the best they can do.  I would
love them to give more, but I think using strong wording like this
it's like tilting windmills.  There are operators with 6RD giving
out /60s.  We have IPv6, if you put more barriers on IPv6 deployment
you're going to decrease IPv6 deployment which still needs to happen
in many parts of the World.

Lorenzo Colitti: I think this is a tousle.  I disagree with everything
Barbara said.  I think we have to say something, and explain what
you can and cannot do with a /64.  We have guidance in the RIR
policies regarding this.  We wrote documents 10-15 years ago about
address sizing before IPv6 was deployed, before we had operational
stories/successes.  Now there's no reason why you can't do a /56.
We have to say something here to guide operators and avoid them
just following what everyone else is doing.

Erik Kline: Is this the right direction to work towards?  Aren't
the RIRs more appropriate for this ?  Jordi:  I think they need to.

Mark Andrews:  There's nothing stopping any 6RD operator deploying
a /48 to everyone of their users.  What we really need to do is
stop trying to describe how to not waste addresses.  We need to
explain how to do things right.  In case of an enterprise with a
/48 and you have 65k networks, you don't require internal structure.
That's a way to waste addresses.  Giving guidance to the end users
on how to not waste addresses would be better.  Jordi: Thank you.

Geoff Huston: We endlessly repeat these conversation and we don't
make any progress.  Trying to do one size fits all creates a wrong
assumption and helps waste addresses.  I do not see anything in
this draft to justify doing it.  Just try to explain why a /64 for
end sites is wrong.  Recommend to listen to customers and do
appropriate assignments.  Let's not repeat this, and move on to
areas that are more productive.  Jordi: Thank you.

Lorenzo:  We need something to discourage a single /64.  I think
it's worth writing a document discussing what we learned and what
it should look like in the future.  Jordi: Some RIRs use a /56,
some others a /48.

Geoff:  The RIRs feel very strongly that one size does not fit all.
There is a charging structure where more space == more money.  No
one inside the RIRs is discussing about network sizes.  Jordi: Some
RIRs do have policies.  Geoff:  RFC6177 Says to not go down the /64
path.

Suresh Krishnan: Just pushing back on the last one:  We had this
discussion and recommended 3GPP to not go down that path.  I want
to avoid mobile networks going that way, and it has been already
discussed, so for mobile networks it's done. We created a recommendation
and I don't want to re-open. Everything has been said in RFC7934.

Eric Vyncke: (from jabber on behalf of Brian Carpenter): 6177 says
"Hence, this document still recommends giving home sites significantly
more than a single /64, but does not recommend that every home site
be given a /48 either."

Bob Hinden:  If we use /48 we will run out of addresses soon.  We've
already been there.  My thinking was that ISPs can manage addresses
usefully.

Lorenzo:  What if we said that giving a single /64 per site is not
recommended ?  Can we state it in a simple way ?  As for mobile
networks, I remember one of the earliest adopters of IPv6, and they
were convinced that a /64 per device was wrong.  After deployment
they realized that it was the right choice to do (for 464XLAT).  We
should say that if an LTE network is an alternative to home network,
then it should assign a /56 or more. I think this would be a good
statement to put somewhere and it would be useful.

Ron:  I like what Lorenzo said, recommending to not use a /64.
There's a need to specify an upper limit, and an area where we give
operators free range.  Now, what is that upper limit ?  Your analysis
was humorous, but we have to have supporting facts.  Maybe you could
discuss with Lorenzo about this upper limit.

Suresh: There are limitations on cellular networks.  In a fixed
networks, people can ask for more space.  The way cellular networks
are, they get a fixed size assignment.  Adding prefixes to a session
is really hard.  We figured out how to delegate a prefix with a
hole in it.  What I'm saying is that the /64 discussion in 2002 was
very painful.  Whatever number we want to discuss about now will
be equally painful.  I'm happy to have the discussion, but it can
be an issue.

Geoff Huston:  I'm just going to remind the IETF about where we
are.  RFC6177 is a BCP.  Where does address allocation policy belong
in the internet ?  We told the RIRs "we give you architecture
guidance". The IETF Can recommend, but cannot enforce.  You can't
tell the RIRs what to do.  That's behind the IETF's scope.  Everything
we're discussing is already stated.  The real issue is that the
guidance should come here, but the feet on the ground belongs to
another room.

Eric Vyncke: (From Jabber on behalf of Brian Carpenter): 6177 really
does say that /64 is too small and /48 may be too much, so apart
from making people read 6177 again, what is new?

Lorenzo: We need to remind that 6177 was written when deployment
was still very low.  It's strange it was a BCP back then.  When it
says "don't do /64" there are good reasons for it.   Just make it
in clear wording.

Lorenzo:  I think this should be a SHOULD.  How many people can
disagree with that ?  RIRs already agree with this. If we want to
add what we learned in this period of time, let's do it.

Jen Linkova: It looks like we think there were a few sections in
the original RFC6177 were not clear enough. Maybe we should just
create an update that clarifies those sections. It doesn't seem to
be a real problem.

Ron: At this point we have to close conversation, and steer discussion
to the mailing list.

Jordi: Please make a diff between original 6177 and this document
to understand.  This is shorter than the original one to make it
simpler.

Fred: Let's take this to the list.

There were no more questions nor comments.

################## Pros and Cons of IPv6 Transition Technologies
for IPv4aaS 2018-10-06, <draft-lmhp-v6ops-transition-comparison>
##################

Jordi Palet presented slides.

Barbara:  I think it would be useful to list the options of the
different technologies on how you can set them up.  It would be
useful to know what the most common configurations are.

Ian Farrer:  I've had a look at the document and I'll post the
comments on the lists.  There is a spreadsheet floating around
listing the transitioning mechanisms.  Is there a plan to incorporate
it into the document (YEs).  Can anything meaningful come out of
this discussion about performances ?

Jordi:  We still don't know how, but I'm not sure how to do it.

Ian:  You can't come out with anything meaningful if you compare
these mechanisms, with different software and hardware comparisons.

Jordi:  I agree.

There were no more questions nor comments.

################## Any other Business if there is time, we will
take volunteers from the floor ##################