V6ops Status PagesIPv6 Operations (Active WG)
Ops Area: Ignas Bagdonas, Warren Kumari | 2002-Aug-22 —Chairs:
IETF-105 v6ops minutes
Session 2019-07-22 1550-1750: Sainte-Catherine - Audio stream - v6ops chatroom
IPv6 Operations - IETF 105 Monday 2019-07-20 15:50-17:50 Chair: Fred Baker, Ron Bonica Notes: Barbara Stark Jabber: Éric Vyncke Agenda IPv6 Deployment at Liquid Telecom by Andrew Alston 464XLAT Optimization 2019-06-20, <draft-palet-v6ops-464xlat-opt-cdn-caches> Neighbor Cache Entries on First-Hop Routers: Operational Considerations 2019-07-02 , <draft-linkova-v6ops-nd-cache-init> Operational Security Considerations for IPv6 Networks 2019-03-11, <draft-ietf-opsec-v6> Possible AOB IS-IS Multi Topology Deployment Considerations 2019-05-19,<draft-chunduri-lsr-isis-mt-deployment-cons> IPv6 Point-to-Point Links 2019-07-04,<draft-palet-v6ops-p2p-links> IPv6-Only Terminology Definition 2019-07-03,<draft-palet-v6ops-ipv6-only> ================================= Chair Introduction Note Well (displayed from website) Agenda (displayed agenda from website) Noted that title of last "Possible AoB" item is wrong on published agenda. Title is correct in minutes (above). ================================== IPv6 Deployment at Liquid Telecom by Andrew Alston Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-liquid-telecom-ipv6-deployment-00 Memorable quote: If you tell vendors you will return equipment if they lie to you about its capabilities, the vendors will tell the truth. Jordi Palet Martinez: You meant "transition" mechanisms and not "translation". Andrew: Yes Jordi: WG just published RFC 8585. You should ask for CPE vendors to do this. Uma Chunduri: There are routers where you cannot push more than 4 labels. Do you see this? Andrew: We see this at edge and sometimes elsewhere. We solve this by using binding labels. That works in environment where you can automate. You also have challenges with end-to-end POS testing. Andrew: I'm around if anyone wants to ask questions later. =================================== 464XLAT Optimization 2019-06-20, <draft-palet-v6ops-464xlat-opt-cdn-caches> Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-464xlat-optimization-00 Presented by Jordi Palet Martinez Erik Kline: It's not just about other names that have the same IP address. It's also about IPv4 literals. Jordi: But then the EAMT isn't created. It's only created if you have the query. Erik: What if there is a string literal on a page. This is why original NAPT was deprecated. You're reiventing NAPT. Jordi: I need to think about that. Éric Vyncke: The name needs to be changed because it's wider than just 464xlat. Warren Kumari: Doesn't it break DNSSEC? Jordi: DNSSEC may already be broken. Jared Mauch: Our customers pay us [CDN providers] to work in all situations. This seems infeasible in practice. Jordi: Akamai said they didn't want to use special addresses. So things that work better than manual assignment of addresses are good. Jared: I think this may cause end user experience to be poor and they may be better off going through a NAT. A lot of coordination is required to do this. You see this also playing out in other WGs. Also issues related to tunneling. There are reasons why this is cool but also reasons why it won't work. Alejandro D'Egidio: I like 464xlat as network operator. But I can't implement this transition mechanism because we would need to deliver traffic through the NAT64 to the set top boxes that are still IPv4. Having NAT in the middle is not good. With direct connections we get better performamce. So that seems like right way to optimize the network. Andrew: If you add a fake record to make this works, that's ok if someone is behind this. But if you have v4 client outside, it's going to cause significant degradation. If there were a real v4 address, it will break people that aren't behind it. Jordi: [goes to slide 15] If you do this you will solve problem for IPv4-only devices. Andrew: It won't work. There is rule that if it won't work, it must fail fast. If there is problem, the delay in non-working v4 address will cause long failure. Jordi: We will proably split into 2 documents. Igor Gashinsky: Majority of CDNs use CNAME. Which are you going to fake when they don't match? Jordi: From CPE, if I do A query to a domain, I will go to another place. But now I'm telling domain I'm not an IPv4 device. There's no way to know. Igor: But let's say you do that. And I'm trying to go to New York but it sends me to San Francisco. Jordi: But I will get the same response. Igor: You may or may not get the same device. If you are a real IPv6 device, the content provider will take responsibility for making sure things work. Jordi: We really need people from CDNs to tell us if this work. Please tell us on the list. Igor: Some apps don't support v6 because of logging or security requirements. If you try to spoof them, it will break things. Jordi: We're trying to avoid that. Please help. Igor: The problem is you're making a decision in the emiddle without knowing what either side needs. Warren: Is the CPE supposed to spy on all DNS traffic or only the traffic that uses it. Jordi: Only devices that use the CPE are impacted. Fred Baker: Need to close discussion. Draft needs more work. ================================ Neighbor Cache Entries on First-Hop Routers: Operational Considerations 2019-07-02 , <draft-linkova-v6ops-nd-cache-init> Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-neighbor-cache-entries-on-first-hop-routers-operational-considerations-00 Presented by Jen Linkova Warren: Please go to slide with ARP. This was a problem. We solved it in v4 by doing opportunistic increase. It's a problem in v6. We should fix in v6 with same answer. Lorenzo Coliti: Windows used to send certain messages. Jen: I suspect there was reason why they did this. Lorenzo: Have you checked to see if answer survives optimization. Jen: I checked one and it did. If it doesn't it may be because code is not present. Jared: We should update to make it explit. Change SHOULD NOT to something that recommends it. We need to give explicit guidance to router vendors. It looks like iOS does this. Igor: Yes this is a massive problem. The vendor doing glean on DAD is doing so at our [Verizon] request. We were told we could not modify the protocol, so we didn't. I can provide text for proposed protocol changes. I didn't want my iPhone to be able to take out a data center. Fred: We are allowed to provide operational work-arounds. It sounds like we need an erratum against RFC 4861 that says "we do this". It needs to say advice doesn't apply to routers. And we need to provide guidance. Warren: An erratum can't provide a change to something. Fred: Then we need to do this. Warren: We should take this to 6man and ask them to do the patch. Fred: OK, we'll do that. David Lamparter: The Wi-Fi controller's job is to interfere with neighbor traffic. Jen: I think we're fine unless a particular router vendor ignores neighbor advertisement. <there was vigorous off-mic discussion> Erik: You need to provide explanation for why this should be ignored. Did you ever try providing a router alert on this? Jen: No. Tim Winters: Make sure it only goes to all routers and not all nodes. And we [UNH-IOL] have plenty of implementations if you need to know what they do. Lorenzo: We want to be careful about what current implementations do. We don't want to chew up bandwidth. David: With a privacy address you at least have a little privacy. Igor: This is why we wanted to do glean on DAD. Jen: Can we call for adoption? Fred: We'll do adoption call on the list. But let's get sense of the room. If you think we should adopt, hum. <There was considerable humming.> If not, hum. <There was silence.> ================================ Operational Security Considerations for IPv6 Networks 2019-03-11, <draft-ietf-opsec-v6> https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-operational-security-considerations-for-ipv6-networks-00 Presented by Éric Vyncke Nathalie Trenaman: Every time at IETF there is a presentation on this draft. There are comments and then updates. But I think it's done. Jordi: I think it's done. There are just a couple of nits. I still disagree with not distinguishing between MAP-E and MAP-T because they have security differences. Lorenzo: Your strategy of trying not to change anything is good. You need to update reference to ULA considerations doc because that's not happening. Jordi: In my March review I provided suggested text that can be used instead. Éric : I don't want to trash ULA. Lorenzo: I think text you have is ok. You just need to remove reference. Éric: I would like this community to review and send comments to OPSEC. Fred: Can I get 2 people to coordinate with Éric? <Jordi and Nathalie volunteered.> ================================= IS-IS Multi Topology Deployment Considerations 2019-05-19,<draft-chunduri-lsr-isis-mt-deployment-cons> Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-aob-is-is-v6mt-deployment-considerations-00 Presented by Uma Chunduri Uma: Please provide feedback in v6ops. Fred: Please provide comments in list and we'll send summary across. ================================== IPv6 Point-to-Point Links 2019-07-04,<draft-palet-v6ops-p2p-links> Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-ipv6-point-to-point-links-00 Presented by Jordi Palet David: You're missing at least one option to assign at least one /64 to a router. Jordi: Thanks. Please send comments to the list. =================================== IPv6-Only Terminology Definition 2019-07-03,<draft-palet-v6ops-ipv6-only> Presentation: https://datatracker.ietf.org/meeting/105/materials/slides-105-v6ops-ipv6-only-terminology-definition-00 Presented by Jordi Palet Jordi: This is simple document. We need to agree on terminology. Please go to the list and discuss.