V6OPS minutes, IETF65 23rd March 2006 Started with document status review and review of agenda IPv6 in CableLabs DOCSIS 3.0 (Alain Durand) ---------------------------------------------------------------- [This talk was also given by Ralph Droms in the Internet Open Area meeting] Alain Durand presented on the DOCSIS 3.0 standard, why IPv6 is of benefit, and how IPv6 would be used. IPv6 is used for provisioning devices (e.g. set top boxes) as well as general IPv6 connectivity to the home. Ipv6 can also be used to manage the ISP's infrastructure (independently of the service to the end user). DOCSIS modems may use IPv4, IPv6, or be dual-stack, and will be provisioned with DHCP and/or DHCPv6. Some will act as L2 bridges, some as L3 routers. Alain described various features/protocols they should support, e.g. use of DHCPv6-PD, supporting MLDv2 proxy, implementing appropriate MIBs. [Question on slide 6] Savola: Is access model 2 using Layer 2 or also Layer 3? Durand: In this case it's L2. If it was L3 there would be switch to disable routing functionality and allow bridged mode. We want to avoid routers back to back Savola: Do service providers support the mode being changed? Durand: That will be provider dependent Savola: So you (Comcast) do not support two routers back to back? Durand: We can, via prefix sub-delegation for cascading routers : Why do you choose different prefixes for provider and customer 2 prefix? Durand: For traffic segregation. Can use a /64 inside the /48 delegated by DHCP-PD. In this case all segments in red in the diagram share the same prefix. The prefix is set on the CMTS The yellow prefix is set by DHCP-PD? : No, it is one address assigned by DHCPv6 : OK [Slide 7] Mundy: DOCSIS supports address filtering for IPv4, is the same capability available for IPv6? Can you check that the source IP is what it's supposed to be? Durand: Yes Mundy: Is that the default? Durand: I don't know Baker: That's something you configure JF Milet(?): It's in a CM configuration file. There's no default we provide, MSO's can do as they please Baker: Good recommendation that they do that Bound: Yes Durand: Yes Savola: Your thoughts for what names in the DNS might look like? Durand: It will be something like customer25.pennsylvania.comcast.... Savola: In many cases the name encodes the IP(v4) address Durand: The operator can do as it pleases. Should be human readable/writeable. ???: Is there any multihoming support? Durand: Shim6 is not of interest here ???: Do MSOs plan on managing devices behind CMs? Durand: No. Shiller: What about multiple IP addresses assigned to hosts behind CM? Durand: No answer ???: DOCSIS offers connectivity, it does not require how CPEs behave, so not sure what your question is about. Recommendations on how the network behaves would be useful Baker: Pictures show devices not in DOCSIS. Might be complexity in the home network (many subnets). Are assumptions being made that limit that complexity? [On forcing DHCPv6 over RA] Hain: Empty prefix list may break a bunch of hosts, doesn't buy you security, nothing prevents manual configuration. Durand: It's part of the IPv6 spec. Talk offline. Durand: For IPv4-only and IPv6-only systems, the MSO will need to consider 'translation' or interworking mechanisms (at some layer). Something to keep in mind. Baker: You may have IPv4 devices that need to speak to IPv4-only. Are you asking where the translator should be? Durand: Yes. And it may have specific functionality, like a VoIP device Dashkano?: Are these general devices or DOCSIS devices? Durand: Can be anything, e.g. SIP or VoIP device. Could be translated at Layer 3 or Layer 7, for example. The solution space is large. The v6ops community needs to solve this and they've been looking at it for a long time. Hain: Could do at application layer, but do we need to revisit the push of NAT-PT down to Experimental status? Durand: I don't want to go into the solution space Hain: I'm just raising the flag. Let's not push NAT-PT to Experimental too soon. Durand: I doubt NAT-PT as it exists will work here. There may be a need for a Layer 3 solution, so its an issue that needs to be reopened, not necessarily NAT-PT Hain: Let's not push to hard to change status of NAT-PT spec. Baker: So let's come up with something that addresses the NAT-PT issues Hain: Yes, that's supposed to be happening in parallel in v6ops Savola: Any idea of communication patterns of IPv4 MTAs; can they talk to other IPv4 MTAs? Durand: Yes JF Milet?: This problem is not specific to cable, see 3GPP and IMS Release 6 and 7. They use some ALG for SIP signalling and a transition gateway for RTP using NAT-PT. We're sidetracked by one app; we should look more generally and look at 3GPP. Focus should be the functionality needed in CM systems so we don't harm the network. Baker: Question is how do we build the network, part of which may be DOCSIS systems; why not have both IPv4 and IPv6 on the MTA? Durand: Will have millions of them; there's not enough address space Baker: But MTAs are already deployed? We're just adding IPv6? Durand: There are new deployments by the millions. JF Milet: MTA specs only support IPv4 now; there is a project for IPv6 support in upcoming MTA specs. No clear direction yet on whether we'll see IPv6-only or dual-stack devices. Durand: Just raising awareness here of types of systems that are planned and that we don't have good solution. Baker: You'll post the draft for this work on Monday? Want it to be WG document? Durand: It's targeted as Informational JF Milet: If useful to have it as WG item that's fine. Kurtis: How many in WG would like to see it as WG item? Savola: How many have read? Kurtis: None yet, it's not out! Savola: Premature! Kurtis: Just getting a feeling for the WG view Chown: If we need to find solutions, let's document the problems. ICMP Filtering Draft (Elwyn Davies) ------------------------------------------------- Some minor updates made, cleaned up references. Added Linux netfilter example. Davies: Do we need more examples? Savola: Would be nice, but surprised at the example's length Chown: Seconded Davies: OK, we'll go with it as it is Davies: Need to decide the status, as a BCP, or as Informational? probably go Informational now, and BCP after experience is gained. Baker: Seems wise to me Davies: Any objections? Chown: Just one person used the example? Davies: Yes Baker: OK I'll look for new draft then I'll WG Last Call it IPv6 Routing Policies Guidelines (Marc Blanchet) -------------------------------------------------------------------- Current guidance may be a little dated, e.g. RFC2772 on 6bone guidelines, so the idea here is to update the guidance, and collate BCP from many recommendations in scattered documents. Marc cited examples of prefixes that should be filtered. Looking for comments, and asking for WG adoption. Chown: Maybe mention old site local prefix? Blanchet: OK Kurtis : I think we have various RFCs for IPv4 that get updated; it's fairly dynamic. In general its good, and I'd also add ingress filtering. Very few prefixes that should be filtered forever; for the rest of it should filter unallocated space on some basis, but need to keep the list of those up to date, and if you can't do so, then don't filter. Blanchet: OK Durand: It's a good idea. Look at draft-andrews-full-service-resolvers-02 in dnsop, looks at a different perspective. The list of prefixes has some similarity. Baker: Suggest they work together? Durand: Yes Savola: We're obsoleting old 6bone document. Concern that if we create a detailed document it means an assumption that the IETF keeps an up to date document? But do we? For example new Teredo prefix(es). Kurtis: We have this for IPv4 Savola: I think that is RFC3330 or something like that describing invalid prefixes. This text describes more. So its slightly different; more generic. Kurtis: So you want a single IPv4 and IPv6 document? Savola: Yes. Durand: Should this be listed in an IANA registry? Blanchet: Not that useful for an end site Baker: Add caveat to the document Baker: Any objections to being WG document? Address Planning Considerations draft (Tim Chown) ----------------------------------------------------------------------- Presented by Chown as VanDeVelde was unable to attend Hopefully someone else took microphone notes :) WG adopted Guidelines on numbering p2p links (Jordi Palet) ----------------------------------------------------------------- A short document suggesting one way to number p2p links, and why to use a /64, and why /127 is harmful. Suggests numbering the p2p link with the first /64 of the /48 allocated to the customer. Would like WG adoption for the document. Baker: Some discussion of rolling into the address considerations document Palet: Specific p2p link numbering probably not a focus of the considerations draft Dupont: We tried the same idea; not a good idea Chown: Presumably DNS problems if ISP 'owns' a /64 out of the /48 that the customer wants to use? Durand: This is one way to number; we don't want to bless just one way. Also reserving bits is not good for specific semantics like this Palet: This is one way Baker: Title suggests it's the best way Droms: What was the DHCP-PD problem? If you give the /48 to the CPE it can use any prefix, so how do you prevent the CPE using the p2p link's /64 prefix? Palet: It's implementation specific(!); not clear from spec whether CPE should delegate from the bottom or top of the available prefix Droms: Can you show me text? Palet: No, it's not clear Droms: You must state the incompatibility clearly that the requesting router must not use the uplink prefix. Shiller: Very simple solution; ISP delegates a /49 Durand: Illustration of a problem of what happens when you try to reserve bits for a special use, and thus it's bad Savola: This doesn't work if the p2p link is Ethernet J Durand: Do you say why we need to number the p2p links? Palet: I think so. But some people prefer to use link local. Venaas: Not sure this is needed. Too many documents already. Savola: If we think we need p2p guidance, avoid numbering information Baker: Keep document individual now, not a WG document Wireless Broadband Scenario (M Shin) ------------------------------------------------------- Discussing use of IPv6 for WiMAX ISPs, extending the bb-deployment-scenarios draft. No questions. Baker: Is this ready for WG adoption? Ent-Analysis future (no presentation) -------------------------------------------------- Baker: Do we feel the comments from the previous last call were addressed? Savola: I think it's better but there are certain bits I don't like, e.g. the appendix on the mission criticial network description. Savola: The text on tunnelling IPv4 in IPv6 has got better; I'd like to see minor changes to it. Maybe mention softwires. Baker: Note what rough concensus means. Need general consensus, as opposed to groups of people whose opinions differ. Are there dissenters? Baker: Opinions on appendix? Durand: I have no problem. Please do add a softwires reference. Bound: The appendix emphasises the importance of the analysis to the reader. How should I use appendices? Baker: I personally put normative stuff in the main text, and add supplementary material in appendices. Kurtis: I don't see any problem with scenario specifics in the appendix Savola: I think the appendix is not representative of the enterprise scenarios Chown: So just put it in context of previous scenario work? Savola: OK Bound: OK IPsec tunnels future (no presentation) ---------------------------------------------------- Went through WGLC in August 2005. Considered done at IETF64, and since added one maintenance update. So is this ready to publish? Dupont: I believe the goal was to have a compliant implementable solution. I think you need some more details in the document, including in the mobile area with transport mode. Savola: We chose to exclude mobike. Dupont: Yes, you need something to update the endpoint addresses, and this is the job of mobike, but you can do it another way. Savola: So what do you suggest? Dupont: Need IPsec person to help you have a better document, to improve it Kurtis: So get someone from the security directorate to read it? Dupont: Yes Romanescu?: Just approach the security ADs and ask Savola; It has had some review, it could have more, we haven't yet had it. Dupont: There have been new IPsec RFCs in December since last call Savola: I am referencing these in references Dupont: It may need more than just changing references Baker: I've not seen these comments on the list, can you send them to the list? Dupont: OK Palet: I think it is ready. Port Scanning future (no presentation) ----------------------------------------------------- Cited in two docs heading IESG-wards - NAP and ICMP filtering