Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

[Ray Hunter <[e-mail]>]

That is not reflected in the current document.

What I read in the title and abstract is a standards track document 
defining "Basic Requirements for IPv6 Customer Edge Routers" not 
"Requirements for Basic IPv6 Customer Edge Routers (Supporting Only 
Directly Connected Hosts)"

  Hemant Singh (shemant) wrote:
> Ray,
>
> Let me try on the big picture for you.  RFC 6204 is the Basic IPv6 CE
> router specification that covers ONLY a single IPv6 router in the home
> for WAN and LAN properties.   After RFC 6204 was released we embarked on
> a bis document to cover a two-router (connected back-to-back) scenario
> and complex features that just could not get consensus for RFC 6204.
> These were features such as routing, prefix delegation, multi-homing and
> source-based IPv6 routing, DNS, MLD Proxy for multicast, mDNS, etc.
> Recently when homenet was formed for an IETF WG, it was decided to take
> the LAN section of the bis document to homenet and move IP Transition
> tech in RFC form to a new rfc6204bis document so that a new version of
> the Basic document could be released ASAP with IP Transition tech.  Thus
> anything that is not included in the current rfc6204bis is all moved to
> homenet.
>
> Hemant
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Ray Hunter
> Sent: Saturday, October 22, 2011 3:46 AM
> To: [e-mail] WG
> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
>
> Following all IMVHO and not directed at any particular participant.
>
> I have been attempting to follow this discussion, as well as Homenet.
>
> After reading many documents including: RFC6092, RFC6333,
> http://tools.ietf.org/html/draft-chown-homenet-arch-00, all the other
> Homenet discussion emails,
> http://tools.ietf.org/html/draft-ietf-pcp-base-16,
> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-01
>
> I have to admit I simply just don't get the big picture of how these
> will stack up operationally.
>
> It seems to me that there are still many implicit assumptions being made
>
> that there's a nice neat stack of boxes connected together in a
> particular order, carrying out particular functions, and which isn't
> actually explicitly documented anywhere in a consistent manner
>
> e.g.
>
> one end user device - one CPE (owned by the ISP or the home user,
> running IPv6 firewall and IPv4 NAT+firewall) - transparent internet
>
> one end user device - one CPE (owned by the ISP running IPv6 firewall +
> DS Lite) - one AFTR running CGN for IPv4
>
> one end user device - one CPE (owned by the end user running IPv6
> firewall + DS Lite) - one AFTR running CGN
> [the end user device then has to comply with all of the ISP's demands
> for DS-Lite and all other items in 6204bis]
>
> So for example, an assumption is made that there'll never be double
> NATv4. Well I already have double NATv4 *within* my homenet. And I can't
>
> turn it off.
>
> I just don't see anyone addressing the practical management problem
> that:
>
> i) the ISP has a bunch of stuff and demands and things to configure
> (like DS-Lite, PPPoA, login passwords) that are highly technical, and
> are very ISP network infrastructure focused.
>
> ii) the home user has a bunch of stuff and demands and things to
> configure (like the wireless ID, print serving, music serving) that are
> non-technical and very personal.
>
> I find it extremely unlikely that an end user is going to be able to
> configure stuff like DS-Lite.
> I find it extremely unlikely that an ISP is going to want to manage a
> music server and routed WiFi networks in the home.
>
> As such I find it extremely likely that there are going to be a minimum
> of two (virtual) CPE's. One owned by the ISP and one by the home user.
> And that these devices will have to have the correct functions enabled.
>
> I can't find a protocol anywhere that allows an end node or CPE router
> to discover the real topology stack of NAT box(es) or firewalls(s).
>
> As such I don't see how a typical end node or other PCP client has any
> idea which PCP server to instruct to open or disable what.
>
> Seems to me you need some sort of firewall and NAT discovery protocol,
> or you define that PCP requests should be sent from an end node / PCP
> client to the default next hop router and you then have to hope that it
> has up to date code and acts as a proxy to find the correct devices to
> instruct, or you come up with a definitive service stack of which box
> performs which function and exactly where in the Internet topology, or
> you can expect a lot of calls to the ISP service desks.
>
> With all due respect, I realize of course that ISP's have vast amounts
> of their own operational experience, but perhaps they've been rather
> blinded by NATv4, so that they could potentially learn from the
> principles enterprises apply to their inter-connections (also learned
> through bitter operational experience), where interfaces between
> management domains typically:
> - have clear management domain boundaries and service delivery point
> interfaces
> - are protected and managed using secure protocols such as SSH
> - generally run vanilla native protocols over a point-to-point x-over
> cable running fixed-speed fixed-duplex Ethernet at the trust boundary /
> service demarcation point
> - are statically routed bi-directionally, or use NAT for return routing,
>
> or communicate via a single, agreed, heavily filtered, routing protocol
> e.g. BGP or OSPF
> - rarely, if ever, are complex technology interfaces split across
> multiple management parties, especially if using technology such as
> serial links, tunnels, encryption, ATM, PPPoA, PPPoE etc.
> - if you've got a special need beyond a vanilla requirement, you provide
>
> your own box with your own management.
> - security functions run on devices owned and managed by the person who
> requires the security.
> - transport networks are transparent and should not mix in any other
> functionality (except in a symmetrical manner e.g. tunnel in / tunnel
> out, or compression in / decompression out, from the same management
> provider).
>
>
> I'm afraid that I can't find many of these principles being applied to
> the current set of documents around 6204bis/ PCP/ DS-Lite, unless of
> course you assume that there's one, and only one, CPE router (which is
> not in line with the Homenet architecture and discussions).
>
> regards,
> RayH
>    
>> From:[e-mail]  [mailto:[e-mail]] On Behalf
>>      
>>>   Of james woodyatt
>>>   Sent: Tuesday, October 18, 2011 2:41 PM
>>>   To: IPv6 Operations
>>>   Cc:[e-mail];[e-mail];
>>>   [e-mail]
>>>   Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
>>>
>>>
>>>
>>>   On Oct 18, 2011, at 10:33 AM, Hemant Singh (shemant) wrote:
>>>
>>>
>>>
>>>   	But the PCP base document needs to become a RFC ASAP
>>>
>>>
>>>
>>>   The current revision, I-D.ietf-pcp-base-14 is unsuitable for the
>>>   purposes described in REC-48 of RFC 6092, in my opinion.  I'm
>>>        
> hoping
>    
>>>   that the forthcoming -15 revision will be acceptable, but I don't
>>>   actually see it on the server yet, and some of the more
>>>        
> authoritative
>    
>>>   participants in the working group are balking at being asked to
>>>   consider a new revision of the draft.
>>>        
>>
>>      
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>