Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review)

[Alain Durand <alain_durand@cable.comcast.com>]

[Changing the title of this long thread to focus the discussion and trimming
the distribution list]

We have a trade-off here to make between network stability and application
complexity: either  modify apps to deal with renumbering (ie try
reconnecting, avoid well know literal addresses, use some kind of service
location,...) or to teach application when it is ok to use ULA vs GUA,
especially in referrals.

My take is that the former is simpler and lead to less service calls. The
later introduce the notion that apps have to be aware of the topology, which
I found disturbing.

  - Alain.


On 7/22/08 6:05 PM, "Stark, Barbara" <bs7652@att.com> wrote:

> Please don't change the ULA requirement. I believe ULA is needed. And I agree
> that apps need to be intelligent about the scope of the addresses they are
> using. I do not want to see the ULA go away. It needs to be persistent and
> always there, from my perspective.
> Barbara
> 
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of
> Hemant Singh (shemant)
> Sent: Tuesday, July 22, 2008 5:02 PM
> To: Alain Durand; Ralph Droms (rdroms)
> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi Denis-Courmont;
> v6ops@ops.ietf.org; Wes Beebee (wbeebee)
> Subject: RE: New (-02) version of IPv6 CPE Router draft is available for
> review
> 
> Alain,
> 
> Very sorry, I missed your "*with* address referral" phrase.  Thanks for
> providing the example.  Here is the analysis:
> 
> Yes, if C tries to communicate with B using B's ULA for destination, C will
> also slap its ULA on the packet src address.  Thereafter before the CPE Router
> WAN interface egresses the packet, the router has to comply to ULA forwarding
> rules.  As per section 4.3 of RFC4193, the CPE Router will drop the packet
> (unless the router is explicitly configured for a route to destination ULA)
> and send an ICMPv6 Destination Unreachable to C. Here is the text from the
> RFC.
> 
> [Site border routers and firewalls should be configured to not forward
>  any packets with Local IPv6 source or destination addresses outside
>  of the site, unless they have been explicitly configured with routing
>  information about specific /48 or longer Local IPv6 prefixes.]
> 
> I don't expect the CPE Router to be supporting a site connected to another ULA
> site so the question of any configuration on the CPE Router for a neighbor ULA
> site is out of the question.  Since C gets some error indication, the app then
> needs to figure out fixes in its implementation.
> 
> Sorry, I don't see this as rustication to change the CPE Router permanent ULA.
> Some brain-dead apps need fixing.  I need more people to speak up and give
> their opinion.  I am still open to change.
> 
> Thanks.
> 
> Hemant
> 
> -----Original Message-----
> From: Alain Durand [mailto:alain_durand@cable.comcast.com]
> Sent: Tuesday, July 22, 2008 1:25 PM
> To: Hemant Singh (shemant); Ralph Droms (rdroms)
> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi Denis-Courmont;
> v6ops@ops.ietf.org; Wes Beebee (wbeebee)
> Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
> review
> 
> Hemant,
> 
> You missed the phrase "*with* address referral" in my response.
> 
> Say A & B are inside their home and use ULA & GUA. C and D are within another
> home and are also using ULA & GUA.
> 
> Now, A B C & D enter a 4 way communication where they initially exchange the
> addresses of their pier.
> If A passes C the ULA and GUA of B, C might prefer to use B's ULA because of
> address selection rules and C->B communication would fail or worse, go
> somewhere else.
> 
> There are multiple variants of this. The point is that you cannot expect apps
> that passes addresses to be smart enough to know about ULA & GUA.
> 
> BTw, using DNS does not help at all if you include both ULA & GUA AAAAs in
> your zone...
> 
>   - Alain.
> 
> 
> On 7/22/08 1:17 PM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:
> 
>> Alain,
>> 
>> Sorry I don't understand.  If any node in the home using an ULA sends
>> a packet out the WAN interface of the CPE Router, the src-addr of the
>> packet used is the GUA before the packet heads out of the node
>> because, as we said in our draft, GUA has larger scope.  So any
>> multi-party host on the Internet sees only the GUA.  I will need a
>> specific example to show me how multi-party communications will break
>> down with ULA and GUA configured on an interface of any node in the
>> home behind the CPE Router or if ULA and GUA is configured on the LAN
>> Interface of the CPE Router.
>> 
>> Thanks.
>> 
>> Hemant
>> 
>> -----Original Message-----
>> From: Alain Durand [mailto:alain_durand@cable.comcast.com]
>> Sent: Tuesday, July 22, 2008 11:48 AM
>> To: Hemant Singh (shemant); Ralph Droms (rdroms)
>> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi
>> Denis-Courmont; v6ops@ops.ietf.org; Wes Beebee (wbeebee)
>> Subject: Re: New (-02) version of IPv6 CPE Router draft is available
>> for review
>> 
>> On 7/21/08 12:43 PM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:
>> 
>>> I have repeatedly said, I am not convinced the ULA gets appreciable
>>> complexity into the CPE Router. Our section 5.5.1 has clearly
>>> outlined any complexity and shown it's minimal.  The ULA fixes a very
>>> common problem for the CPE Router which is configuring the router
>>> without any SP access - the problem is not a corner case.
>> 
>> Hemant,
>> 
>> 2 party communications in the presence of mixed ULA & GUA work ok,
>> given proper default address selection rules.
>> 
>> Multi-party communications *with* address referral do not work in the
>> general case in such a mixed environment, regardless of default address
>> selection.
>> 
>>   - Alain.
>> 
>> 
> 
> 
> 
> 
> *****
> 
> The information transmitted is intended only for the person or entity to which
> it is addressed and may contain confidential, proprietary, and/or privileged
> material. Any review, retransmission, dissemination or other use of, or taking
> of any action in reliance upon this information by persons or entities other
> than the intended recipient is prohibited. If you received this in error,
> please contact the sender and delete the material from all computers. GA621
> 
>