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 , ) IPv6-Ready DNS/DNSSSEC Infrastructure (2018-10-10, ) IPv6 Address Assignment to End-Sites (2018-10-09, ) Pros and Cons of IPv6 Transition Technologies for IPv4aaS (2018-10-06, ) 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--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 , ################## 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 , ################## 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: 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 , ################## 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, ################## 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 ##################