Subject: Re: I-D Action:draft-wbeebee-ipv6-cpe-router-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jul 2008 11:16:36 +1200

Hi, some comments on other points.

> 5.3.  Acquire IPv6 address and other configuration parameters

I suggest that if address acquistion by DHCPv6 fails, there
should be a (configurable) option to discover a 6to4
relay. CPE routers were in fact a target when 6to4 was designed.
It only needs a few lines and a reference to RFC 3056 and 3068.

Also I suggest that there should be a configurable option
to generate and support a ULA prefix. Again, a few lines
and a reference to RFC 4193.

> 6.  IPv6 Data forwarding
...
>                                       Each protocol that the CPE
>    Router can forward packets for must have a separate routing table.

I've read that sentence several times and can't understand it. Do you
simply mean that the IPv6 table is separate from IPv4?

...
>                         Before forwarding a packet
>    in any direction from CPE router, the CPE Router will perform a MAC
>    rewrite operation that rewrites the source L2 address of the packet
>    with CPE Router's WAN or LAN interface MAC address.  

I also don't understand that sentence. Surely a router moves an L3
packet from one L2 interface to another, and removing and creating
L2 headers is nothing to do with routing as such?

> 7.1.  Path MTU Discovery Support
> 
>    GRE tunnels, such as 6-to-4 tunnels (which may be terminated on the
>    CPE Router),

This is confusing. 6to4 (no hyphens) refers to RFC 3056 and has nothing
to do with GRE. In fact any kind of Protocol 41 tunnel can interfere
with MTU too - do you expect a typical CPE to support generic Protocol 41
tunnels? I think that by '6-to-4' you probably mean "IPv6 in IPv4"?

> 8.  Quality Of Service(QoS)
> 
>    The CPE router may map the IPv6 Traffic Class field from [RFC2460] to
>    individual queues of different priority to provide differentiated
>    classes of service for traffic either destined to the LAN or WAN
>    interfaces (e.g. for IPTV service).

You shouldn't use the word 'priority' because the diffserv model is
not about priority. Better to use 'behavior' plus a reference to
RFC 2474. In fact, the whole thing can be expressed as

  The CPE router MAY support differentiated services [RFC2474].

     Brian

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 08 Jul 2008 09:35:04 +0200

> It only needs a few lines and a reference to RFC 3056 and 3068.

While I don't necessarily disagree with the high-level idea, I am not a big

fan of automatically configuring 6to4 gatewaying on the sole basis of

having an IPv4 address.

I have had multiple cases of public IPv4 addresses with non working 6to4

relay:

- no anycast 6to4 routing,

- anycast 6to4 relay temporarily broken,

- public IPv4 address space behind a NAT (!),

- stateless firewall that drops proto-41,

- statefull firewall that tracks proto-41 "bindings"...

I wish private IPv4 addresses had the same scope as public IPv4 addresses

within RFC3484 - then broken 6to4 would not be so much of a problem

anymore.

> and a reference to RFC 4193.

Yes.

-- 

Rémi Denis-Courmont

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jul 2008 16:07:53 +1200

> - statefull firewall that tracks proto-41 "bindings"...

Yes, that's why 6to4 absolutely needs to be configurable, preferably
by something less obscure than
netsh interface ipv6 6to4 set state state=enabled

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 14 Jul 2008 15:35:29 -0400

Folks,

Before IETF locks down any new I-D submission today for IETF Dublin, we
thought we'd submit this new copy since we had completed new sections
for PPP over IPv6 and Softwires to accommodate DSL folks. Other minor
review comments have been taken care of as well. Please refer to Change
Log for complete change details.

http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-02.txt

Hemant & Wes.

---

From: Antonio Querubin <[email-masked]>
Date: Mon, 14 Jul 2008 11:06:18 -1000 (HST)

> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-02.txt

I missed this earlier but the definition of WAN interface seems a bit 
restrictive:

"WAN interface - a single network interface on the CPE Router that
       is used to connect the router to the access network of the Service
       Provider."

Remove the word single as some vendors may want to have the option of 
providing additional interfaces on the WAN link for bridging additional 
devices to the subnet directly connected to the service provider. 
Additional WAN interfaces are particularly helpful for facilitating 
troubleshooting of the Service Provider to customer link.

Additionally, for those vendors that wish to integrate the layer 2 
(DSL/cable) modem as part of the CPE router (where the "WAN" encapsulation 
is not ethernet), perhaps a separately named interface definition might be 
appropriate to avoid confusion with "WAN".

Antonio Querubin
whois:  AQ7-ARIN

---

From: Alain Durand <[email-masked]>
Date: Fri, 18 Jul 2008 12:25:54 -0400

I'm reading version -02. I have to first admit I have not read the -01 nor
the other comments that came with it, so some of what I'm going to say may
have been said previously.

Here are my main comments on the draft:

1) Two WAN interface models.

I think this is one too many. Especially is there is a variable that the
customer has to configure to select which mode the router is on. I look at
this as a potential source of calls to the tech support.

Choosing between the 2 modes, I would favor the numbered one. The reason is
that we still have customers who attach a single PC to their cable modem.
Those device would be just as happy with a single DHCPv6 assigned address.

2) ULA

Supporting both ULA & GUA at the same time is also a source of complexity
and confusion. The key problem I see is with external referrals in
multi-party communications where some of the hosts are inside, and some are
outside. Mixing ULA & GUA can have complex consequences, and again generates
service call.

Also, if I read the text correctly, if the WAN interface gets configured
first, no ULA are generated. Which leads to confusing situation depending on
whether the customer turns its modem on before or after its CPE.

I would rather like the text to recommend to only use ULA when nothing else
is available and immediately renumber to GUA when those are acquired.

3) Cascading routers

The text says that the CPE can either be a DHCPv6 server or a DHCPv6 relay.
This needs to be clarified. From an operation perspective, I'd rather like
that the ISP only provision the CPE, not the cascaded routers. With that in
mind, I do not think that the DHCPv6 relay mode is realistic.

4) RIPv6

Running RIPv6 between routers within the home might be OK, although it all
depends on how the distribution of the prefixes is done, maybe a combination
of default route upstream plus a route downstream toward the delegated
router will be enough.

However, running RIPv6 between the CPE and the ISP is a whole different ball
game. We are looking at other solutions (DHCPv6 message interception) for
prefix route injection as route announcement coming from residential
customers are hard to trust.

5) DHCPV6 on the LAN interfaces

First:
"   The CPE Router may include a stateful DHCPv6 server to assign
   addresses to home devices connected via the LAN interface(s) of the
   CPE Router.  However, we recommend that the CPE Router use SLAAC for
   home devices."

I think this recommendation is too strong and basically says "don't run
DHCPv6 stateful on the LAN". This is in conflict with the statement to run
DHCPv6 stateful with PD for cascading routers. I'd like this text to adopt a
more neutral tone wrt DHCPv6 stateful configuration.

Another example: I found it was not spelled out if the CPE MUST implement
stateless DHCPv6 or not. It is not spelled out either if the CPE SHOULD
implement a DNS server and advertize itself as such in DHCPv6 messages or if
the CPE SHOULD re-advertize the ISP DNS server address...

There is also no mention about NTP or any other similar options.

As such, I think this whole section need more work.

6) Softwire & dual-stack lite support.

We are moving the dual-stack lite work to softwire. See
draft-durand-dual-stack-lite-00.txt

If this gets adopted, I'd like to see support for it required in this draft.
The minimum requirement is to support IPv4 over IPv6 tunneling, with manual
configuration of the tunnel endpoint.

  - Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Jul 2008 12:40:53 -0400

Alain,

Thanks very much for the careful review. We are working closely with
Mark Townsley at Cisco who told us about your draft and Ralph's SNAT.
Mark has advised us that our CPE Router draft needs to track all
softwire new work and any IPv4 address depletion solutions like yours.
In our next version we will mention such tracking in our draft including
mention of your draft. 

I will reply to rest of your comments sometime later today or over the
weekend.

Regards.

Hemant  

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, July 18, 2008 12:26 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

I'm reading version -02. I have to first admit I have not read the -01
nor the other comments that came with it, so some of what I'm going to
say may have been said previously.

I think this is one too many. Especially is there is a variable that the
customer has to configure to select which mode the router is on. I look
at this as a potential source of calls to the tech support.

Choosing between the 2 modes, I would favor the numbered one. The reason
is that we still have customers who attach a single PC to their cable
modem.
Those device would be just as happy with a single DHCPv6 assigned
address.

2) ULA

Supporting both ULA & GUA at the same time is also a source of
complexity and confusion. The key problem I see is with external
referrals in multi-party communications where some of the hosts are
inside, and some are outside. Mixing ULA & GUA can have complex
consequences, and again generates service call.

Also, if I read the text correctly, if the WAN interface gets configured
first, no ULA are generated. Which leads to confusing situation
depending on whether the customer turns its modem on before or after its
CPE.

I would rather like the text to recommend to only use ULA when nothing
else is available and immediately renumber to GUA when those are
acquired.

3) Cascading routers

The text says that the CPE can either be a DHCPv6 server or a DHCPv6
relay.
This needs to be clarified. From an operation perspective, I'd rather
like that the ISP only provision the CPE, not the cascaded routers. With
that in mind, I do not think that the DHCPv6 relay mode is realistic.

4) RIPv6

Running RIPv6 between routers within the home might be OK, although it
all depends on how the distribution of the prefixes is done, maybe a
combination of default route upstream plus a route downstream toward the
delegated router will be enough.

However, running RIPv6 between the CPE and the ISP is a whole different
ball game. We are looking at other solutions (DHCPv6 message
interception) for prefix route injection as route announcement coming
from residential customers are hard to trust.

First:

I think this recommendation is too strong and basically says "don't run
DHCPv6 stateful on the LAN". This is in conflict with the statement to
run
DHCPv6 stateful with PD for cascading routers. I'd like this text to
adopt a more neutral tone wrt DHCPv6 stateful configuration.

Another example: I found it was not spelled out if the CPE MUST
implement stateless DHCPv6 or not. It is not spelled out either if the
CPE SHOULD implement a DNS server and advertize itself as such in DHCPv6
messages or if the CPE SHOULD re-advertize the ISP DNS server address...

If this gets adopted, I'd like to see support for it required in this
draft.
The minimum requirement is to support IPv4 over IPv6 tunneling, with
manual configuration of the tunnel endpoint.

  - Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Jul 2008 15:24:17 -0400

Alain,

Please see in line between <hs> and </hs>. After Wes and I have
discussed your comments, we will update folks another time.  I won't be
able to talk to Wes before Thu next week.

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, July 18, 2008 12:26 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

<hs>
Even currently, a standalone Linksys like router needs to pick if DHCP
or PPPOE is used for WAN connection. At least an old version that I have
at home.  The default with Linksys is DHCP.  We can suggest one default
like DHCP, but if a DSL user uses the CPE Router, they will have to
provision the WAN port like it is done with Linksys today.  Anyhow, the
unnumbered model is something that a lot of DSL folks have asked for. We
have got to keep it. We have tried to automate as much as we can like
spawning a loopback interface with unnumbered model.  If any further
auto-detection is possible, we will suggest it to make the SP life
simpler.
<hs>

2) ULA

<hs>
Sorry, I don't see the point yet.  We have clearly shown in section
5.5.1 how both ULA and GUA will coexist including very simple source
address selection (SAS) rules pointers in the section.  Other folks
haven't balked at this yet - feel free to jump in.  Renumbering is an
extra step.  If you renumber ULA to expire and shoe-horn in the GUA,
service will be disrupted for a little while. ULA's are also
automatically generated, so the operator hasn't see any of it or any
support calls.
</hs>

<hs>
You read the text correctly. This model is used when the SP controls the
CPE Router or the CPE Router is embedded in a cable or DSL modem etc.
Irrespective of when the modem turns on wrt to its CPE, when the WAN
interface of the CPE Router get connection to the SP, the WAN interface
init will take place. There is no need for ULA here. However, there is
no reason why we cannot have the WAN init first model also follow the
same idea as the LAN interface(s) init first. However, since our
document says, the CPE Router may be embedded in a modem, we needed to
keep this ULA out of the WAN init first model to be compliant with
CableLabs (CL) eRouter CM standard. That standard mandates WAN inits
first, then the LAN inits, then the LAN interface(s) are sub-delegated
the IA_PD. If we add ULA to the WAN init first model, we won't be
compliant with CL eRouter CM standard.

If you want both WAN init first and LAN init first models to always
assign UAL to the LAN interface(s), then CL has to adopt text from our
draft to their eRouter CM standard.
</hs>

3) Cascading routers

<hs>
The text for this section is saying that a CPE Router vendor decides if
the vendor implements a DHCPv6 server or a relay agent in their device
to be able to support cascading of the CPE Router.  SP is not going to
provision anything here. 
</hs>

4) RIPv6

<hs>
Preaching to the choir here. I have already said in this draft's thread
that I prefer the DHCPv6 message snooping.  We just left the door open
if anyone wanted to do anything with RIPv6.  It's optional anyway for a
vendor to support and the SP to decide to use it or not.
</hs>

First:

<hs>
We can consider toning down the language.  For the case when the CPE
Router is embedded in a cable modem, we do not expect a cascading of
router(s) behind the eRouter CM. That is why we have an "if" in the
cascading section. It's left to the vendor to decide if they want to
support a DHCPv6 server or not.
</hs>

<hs>
Section 5.5 says clearly that the DNS server IPv6 address obtained in
DHCPv6 response messages is doled out to clients in the home. This is
the text from section 5.5: "CPE Router can pass Domain Name Server(s)
IPv6 address(es) to home devices.".

In the long-term for our draft, we do need to add support for a DNS
server on the CPE Router to advertise itself in DHCPv6 message as you
say. In our next version we can add a new section placeholder for this
item and the write the text when we get the time. 
</hs>

<hs>
We know about NTP but we didn't get time to do our homework on it to
make sure if it's really needed.  We do need to collect all options that
are expected to be used in the home and add them when we compile the
list.  We will add a TBD to this section say such a list is pending. 
</hs>

<hs>
Some work is indeed needed.  We will make sure the section has toned
down language and also complete the TBD's mentioned above.
</hs>

<hs>
I already replied to this one. We will track this draft.  After I finish
reading it, I will send my feedback.
</hs>

Hemant

  - Alain.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Jul 2008 21:57:04 +0200 (CEST)

> this as a potential source of calls to the tech support.

I'm ok with "globall routable WAN IPv6 address" being the default. My only 
request is that the "link-local only WAN" and "assign loopback address for 
management from DHCPv6 PD block"-model is a SHOULD requirement in the 
draft.

> Those device would be just as happy with a single DHCPv6 assigned address.

The service I have in mind would require the customer to have a router, 
otherwise they'll have to purchase a different service.

Basically what I envision is that for single PC deployment we'd run 
tunneling (6to4) or equivalent, and "customer has a proper CPE router" 
would be native IPv6. Single PC is ok to have tunneled as there will be no 
multicast etc in that service. For routed multicast IPv6 you really really 
want to have a CPE router (at least that is my opinion).

I am also looking at this in the 5-10 year future, where I think all 
customers want to have a routed CPE in their home and have multiple 
subnets. Not including "link-local WAN" in the model is too short-sighted 
for me, even though I can understand why people are hesitant about it in 
the short term.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alain Durand <[email-masked]>
Date: Fri, 18 Jul 2008 16:36:38 -0400

> for me, even though I can understand why people are hesitant about it in

There is something I'm missing here: If you give an IPv6 address to the CPE
(using stateful DHCPv6 or SLAAC) and then do a stateful DHCPv6-PD request
from the CPE, what is missing?

  - Alain.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Jul 2008 22:49:57 +0200 (CEST)

> from the CPE, what is missing?

I am not sure I understand the question, but I hope this is a 
clarification:

I don't want to have a common IP network which is shared by the ISP device 
and the CPE device. Thus, no link network that is shared between ISP 
device and customer device (=link local).

---

From: Alain Durand <[email-masked]>
Date: Fri, 18 Jul 2008 16:53:59 -0400

> device and customer device (=link local).

Thank you for the clarification, I now understand better your goal, but what
is the rationale for doing that?

  - Alain.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 18 Jul 2008 23:34:56 +0200 (CEST)

On Fri, 18 Jul 2008, Alain Durand wrote:

> Thank you for the clarification, I now understand better your goal, but 
> what is the rationale for doing that?

I stated this in the beginning of the discussion, but here goes again:

I want to protect ISP equipment from outsid/Internet DDOS attacks. I 
foresee proliferation of basement/FTTC L3 switches (ASIC forwarding, small 
TCAM, small CPU) with ethernet/vdsl2 PHYs, and I want to be able to 
rate-limit traffic coming in from the internet to these devices (also my 
core).

Therefore ISP equipment needs to be in separate IP space from customer 
equipment IP space. This also applies to SOHO market.

---

From: "Ole Troan" <[email-masked]>
Date: Fri, 18 Jul 2008 23:52:38 +0200

> customers are hard to trust.

quite. you can't run RIP in this scenario without solving the glaring
security problem.
http://tools.ietf.org/draft/draft-stenberg-v6ops-pd-route-maintenance/draft-stenberg-v6ops-pd-route-maintenance-00.txt
for details.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Jul 2008 18:18:58 -0400

Right. This was the 3rd solution we had alluded to in our emails but not
pointed to it since we authors are leaning towards the dhcv6 snooping by
the aggregation router. 

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Friday, July 18, 2008 5:53 PM
To: Alain Durand
Cc: Hemant Singh (shemant); [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

> combination of default route upstream plus a route downstream toward 
> the delegated router will be enough.
>
> However, running RIPv6 between the CPE and the ISP is a whole 
> different ball game. We are looking at other solutions (DHCPv6 message

quite. you can't run RIP in this scenario without solving the glaring
security problem.
http://tools.ietf.org/draft/draft-stenberg-v6ops-pd-route-maintenance/dr
aft-stenberg-v6ops-pd-route-maintenance-00.txt
for details.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Jul 2008 18:43:33 -0400

Alain,

Draft dual-stack-lite looks alright to me. Good job.

Since SNAT proposes using a softwire for the v4 in v6 tunnel, the CPE
Router will add support for such a softwire. We already include a
softwire for v6 in v4 tunnel in our -02 draft. Our draft will leave TBD
for how does the CPE Router obtain dual-stack lite carrier-grade NAT
device IPv6 address.

Hemant

---

From: Alain Durand <[email-masked]>
Date: Fri, 18 Jul 2008 20:14:29 -0400

> Draft dual-stack-lite looks alright to me. Good job.

Thank you!

> for how does the CPE Router obtain dual-stack lite carrier-grade NAT

2 things. 

A) I'd like to use a simpler encap for dual-stack lite. No need for L2TP,
just IPv4 in IPv6.
B) About the tunnel end point discovery, you may simply say that the CPE
must have the option to manually configure it and that a yet-to-be-defined
DHCPv6 option might help.

  - Alain.

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 18 Jul 2008 16:00:27 -1000 (HST)

On Fri, 18 Jul 2008, Mikael Abrahamsson wrote:

> Basically what I envision is that for single PC deployment we'd run tunneling 
> (6to4) or equivalent, and "customer has a proper CPE router" would be native 
> IPv6. Single PC is ok to have tunneled as there will be no multicast etc in 
> that service. For routed multicast IPv6 you really really want to have a CPE 
> router (at least that is my opinion).

Why would a single PC be precluded from benefiting from multicast service 
if it's connection were tunneled?  While there may not be a direct benefit 
to the end-user, the alternative means a content provider would have to 
plan to support more unicast clients.  Even service providers benefit from 
reduced bandwidth in their core regardless of whether multicast customers 
at the edge are just single PCs.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 19 Jul 2008 04:59:25 +0200 (CEST)

On Fri, 18 Jul 2008, Antonio Querubin wrote:

> Why would a single PC be precluded from benefiting from multicast 
> service if it's connection were tunneled?  While there may not be a 
> direct benefit to the end-user, the alternative means a content provider 
> would have to plan to support more unicast clients.  Even service 
> providers benefit from reduced bandwidth in their core regardless of 
> whether multicast customers at the edge are just single PCs.

If you want to deploy native IPv6 multicast in your network, that's your
prerogative. I am not looking at limiting other peoples' choice, I just 
want ability to choose the functionality I feel is important for me (and 
for others in the end).

Of course multicast over tunnels works, it's just that normally a tunnel 
is terminated fairly centrally in the network, and replicating 10-20 meg 
HDTV streams doesn't really scale in that topology. You want the 
replication to happen as close to the customer as possible (DSLAM, 
ethernet switch etc). I see TV as the main driver for multicast, and doing 
that over tunnels is just not feasable to me.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Jul 2008 15:42:23 +1200

On 2008-07-19 04:25, Alain Durand wrote:
...
> is available and immediately renumber to GUA when those are acquired.

IMHO that is only acceptable if there MUST be a configurable option
to support a ULA (generated once per factory-reset) in parallel with
a GUA, if that's what the user wants. I think that is needed for scenarios
where people want addresses for devices that are guaranteed never
to reply to external packets.

    Brian

---

From: David Miles <[email-masked]>
Date: Sat, 19 Jul 2008 13:56:38 +1000

I might add a view on this too:

- Having a global prefix on the WAN interface means a customer is  
represented by exactly two different IPv6 prefixes (in addition to  
their /32 in IPv4) from disparate address space. I am mindful ISP  
routers must perform accounting, rate-limiting/QoS, anti-spoofing and  
ACL on all these addresses. An extra prefix per subscriber is going to  
consume additional resources at a time we are already trying to  
support two prefixes (an IPv4 and IPv6 prefix).

- Increased complexity in the ISP router for IP sessions. For example,  
a DHCPv6-PD uses a rebind message to reconfirm the prefix (state  
machine 1) whereas an IA_NA of the WAN interface uses a Confirm  
message (state machine 2). Two different messages, two different state  
machines, and more places things could go wrong.

- It requires the DR/BNG/CMTS to advertise the WAN shared prefix in  
its RA for on-link determination. As RA go to all subscribers (in a  
common VLAN) you have a P2P consideration where subscribers will  
initiate ND (on multipoint interfaces) for one-another on their WAN  
interface. The router must now perform ND proxy for the shared prefix.

- An advantage of the unnumbered model is that we may not need to  
configure the ISP router with any link information in advance. With a  
numbered model one would normally have to create an IP interface on  
the ISP router and configure RA PIO for the WAN prefix.

The disadvantages I see are:
- Operational troubleshooting. If the WAN interface did respond to  
ICMP echo requests you can test the subscriber state from any Internet  
host.
- Traceroutes. If the WAN interface was link-local, a traceroute would  
indicate the loopback or LAN interface on the CPE as opposed to the  
WAN interface.
- If a loopback interface is used, one may need to devote an entire / 
64 to it - the alternative is to use an always-up LAN interface (ie  
bridge0 interface).

-David

On 19/07/2008, at 7:34 AM, Mikael Abrahamsson wrote:

>> Thank you for the clarification, I now understand better your goal,  
>> but what is the rationale for doing that?
>
> foresee proliferation of basement/FTTC L3 switches (ASIC forwarding,  
> small TCAM, small CPU) with ethernet/vdsl2 PHYs, and I want to be  
> able to rate-limit traffic coming in from the internet to these  
> devices (also my core).
>
> Therefore ISP equipment needs to be in separate IP space from  
> customer equipment IP space. This also applies to SOHO market.
>
> --

---

From: Alain Durand <[email-masked]>
Date: Fri, 18 Jul 2008 23:53:20 -0400

> to reply to external packets.

I'd agree to this if, by default, parallel ULA support is off.

  - Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 20:47:07 -0400

Alain,

Please go back to this draft's emails and see how Wes, I, and Remi
discussed the ULA case and a MUST requirement.  Your idea below is not
valid because you have not considered the case of a standalone CPE
Router that is purchased from retail.  The user will power on the CPE
Router at home and the LAN interface(s) of the router will be up first -
the user hasn't connected the WAN port yet to the broadband network.
The user needs some IPv6 address to configure the CPE Router via the
web.  That is why the ULA will be used.  We have also said in our draft
that manual configuration is out of scope of our draft - therefore we
are not worried about details like how does the user get to know the ULA
prior to logging on to the CPE Router over the web using this ULA.  If
need be, we can also work on such details but there is no dispensing
with ULA.  I too like Brian's suggestion of once per factory-reset and
further I prefer a well-known ULA address publishes apriori in the CPE
Router manuals for the user to use that address to configure the CPE
Router.  After configuration, any other ULA may be generated and the
router reset to use the new ULA and associated ULA prefix(es).

Only for the case when the CPE Router is embedded in a broadband device
like a modem and thus managed by the SP, the ULA's will not be spawned
as this is a WAN init first before LAN init model of our draft.  See my
other comments about WAN init first model also complying with CableLab
docsis 3.0 standards. 

Hemant  

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Friday, July 18, 2008 11:53 PM
To: Brian E Carpenter
Cc: Hemant Singh (shemant); [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

On 7/18/08 11:42 PM, "Brian E Carpenter" <[email-masked]>
wrote:

>> I would rather like the text to recommend to only use ULA when 
>> nothing else is available and immediately renumber to GUA when those
are acquired.
> 
> IMHO that is only acceptable if there MUST be a configurable option to

> support a ULA (generated once per factory-reset) in parallel with a 
> GUA, if that's what the user wants. I think that is needed for 
> scenarios where people want addresses for devices that are guaranteed 
> never to reply to external packets.

  - Alain.

---

From: Antonio Querubin <[email-masked]>
Date: Sun, 20 Jul 2008 21:46:01 -1000 (HST)

> as this is a WAN init first before LAN init model of our draft.  See my

There are some false assumptions there - unless you are making these 
required conditions.  Combination with a modem does not imply the device 
is managed by the SP, nor can you assume the WAN connection is actually 
useable at power-up.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 06:49:33 -0400

No.  See my earlier email to you that said when the CPE Router is
embedded in, say, a cable modem, then the WAN interface of the CPE
Router becomes an internal logical interface (as opposed to a physically
available port in a standalone CPE Router).  The logical interface
bridges to the cable modem.  The cable modem is definitely managed by
the ISP and it is this modem's software that can automatically configure
the LAN interface(s) of the CPE Router.  Cable standards have specified
this automatic configuration by the modem.  The CPE Router when embedded
in a cable modem has to comply to Cable standards. 

When the WAN interface is internal to the modem there is no question of
useable or not.  The interface is not even visible to the user.

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 3:46 AM
To: Hemant Singh (shemant)
Cc: Alain Durand; Brian E Carpenter; [email-masked]; Wes Beebee
(wbeebee)
Subject: RE: New (-02) version of IPv6 CPE Router draft is available for
review

On Sun, 20 Jul 2008, Hemant Singh (shemant) wrote:

> Only for the case when the CPE Router is embedded in a broadband 
> device like a modem and thus managed by the SP, the ULA's will not be 
> spawned as this is a WAN init first before LAN init model of our 
> draft.  See my

Antonio Querubin
whois:  AQ7-ARIN

---

From: Antonio Querubin <[email-masked]>
Date: Mon, 21 Jul 2008 03:20:58 -1000 (HST)

On Mon, 21 Jul 2008, Hemant Singh (shemant) wrote:

> bridges to the cable modem.

No argument there.

> The cable modem is definitely managed by the ISP

Perhaps this is true in some cable broadband networks but in my DSL world 
the DSL modem is un-managed by us and in most cases not by the customer 
either.  Sometimes it's purchased by the end-customer, sometimes by us and 
shipped to the end-customer and it may have some local management control 
if it's got an integral NAPT router but regardless we do NOT manage it.

> and it is this modem's software that can automatically configure the LAN 
> interface(s) of the CPE Router.  Cable standards have specified this 
> automatic configuration by the modem.

On one hand you say "managed by the ISP" and in the same sentence you say 
"modem's software that can automatically configure ... the CPE router".
  ^^^^^                                   ^^^^^^^^^             ^^^^^^ 
My head hurts...

> The CPE Router when embedded in a cable modem has to comply to Cable 
> standards.

If cable standards already define some part of CPE router behaviour, then 
what gaps is this draft trying to fill in?

> useable or not.  The interface is not even visible to the user.

Regardless of whether the modem were a DSL or cable or WIMAX modem, etc., 
if there's no connection to the SP on startup then the WAN interface is 
basically not useable for anything until it does have connectivity to the 
SP.  I think it's desirable that the behaviour and desired end-state of 
the CPE router should be determinate and not depend on the order in which 
the interfaces acquire external connectivity.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 09:51:12 -0400

>> On one hand you say "managed by the ISP" and in the same sentence you
say "modem's software that can automatically configure ... the CPE
router".

>> My head hurts...

Sorry.  Here is Tylenol for your head. It is a MUST in CableLabs (CL)
eRouter CM (cable modem) standard that after the CM has initialized its
cable interface and acquired an IA_PD then the CM MUST configure the LAN
interfaces. 

>> If cable standards already define some part of CPE router behavior,
then what gaps is this draft trying to fill in?

Here are the gaps:

1. CL only specifies an embedded CPE Router.  We are defining a
standalone CPE Router.  There are enough difference between the two. Of
course, CL standard doesn't discuss cascading of routers since one does
not cascade a modem behind another modem.  The standalone router does
need to discuss cascading. The eRouter doesn't need to deal with LAN
init first mode but a standalone router does. The standalone router is
usually NOT managed at all by the SP.  There are numerous other gaps.

2. We are gathering requirements from the DSL world to also define a
standalone and embedded CPE Router suitable for DSL deployment.

3. We don't agree with certain behavior in the CL embedded Router IPv6
and that is why we present our view.

Some of the other reason we wrote this draft are as follows:

1.  We didn't want DSL going off on their own defining a CPE Router and
then break something for cable because cable already has a embedded
router standard defined. 

2. IETF v6ops was discussing security ad nauseam for a home CPE Router,
but didn't have a specification for a CPE Router.  

We have already seen enough evidence in v6ops that folks call all
problems and issues as Broadband issues when they clearly mean to
discuss only DSL.  For example, Cable doesn't need any link model draft
that came out recently that says it's a Broadband model. Yeah, right!
Call it your DSL model.  We know what our cable link, data models are.
We don't need the emails on Broadband/SOHO provisioning - cable has a
working provisioning systems, aggregator, and modem for IPv6 that are
cable standards compliant for IPv6.  

>> Regardless of whether the modem were a DSL or cable or WIMAX modem,
etc., if there's no connection to the SP on startup then the WAN
interface is 
>> basically not useable for anything until it does have connectivity to
the SP.  I think it's desirable that the behavior and desired end-state
of the >> CPE router should be determinate and not depend on the order
in which the interfaces acquire external connectivity.

Totally agreed.  Don't you see our LAN init first before WAN init define
deterministic behavior for a standalone CPE Router?  Our WAN init first
model is also deterministic.  

We'll continue to work on DSL requirements and make some sensible
behavior out of them for the CPE Router.

Hemant 

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 9:21 AM
To: Hemant Singh (shemant)
Cc: Alain Durand; Brian E Carpenter; [email-masked]; Wes Beebee
(wbeebee)

On Mon, 21 Jul 2008, Hemant Singh (shemant) wrote:

> Router becomes an internal logical interface (as opposed to a 
> physically available port in a standalone CPE Router).  The logical 
> interface bridges to the cable modem.

No argument there.

> The cable modem is definitely managed by the ISP

Perhaps this is true in some cable broadband networks but in my DSL
world the DSL modem is un-managed by us and in most cases not by the
customer either.  Sometimes it's purchased by the end-customer,
sometimes by us and shipped to the end-customer and it may have some
local management control if it's got an integral NAPT router but
regardless we do NOT manage it.

> automatic configuration by the modem.

On one hand you say "managed by the ISP" and in the same sentence you
say "modem's software that can automatically configure ... the CPE
router".
  ^^^^^                                   ^^^^^^^^^             ^^^^^^ 
My head hurts...

> The CPE Router when embedded in a cable modem has to comply to Cable 

If cable standards already define some part of CPE router behaviour,
then what gaps is this draft trying to fill in?

> When the WAN interface is internal to the modem there is no question 
> of useable or not.  The interface is not even visible to the user.

Regardless of whether the modem were a DSL or cable or WIMAX modem,
etc., if there's no connection to the SP on startup then the WAN
interface is basically not useable for anything until it does have
connectivity to the SP.  I think it's desirable that the behaviour and
desired end-state of the CPE router should be determinate and not depend
on the order in which the interfaces acquire external connectivity.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 21 Jul 2008 17:57:38 +0300

Le vendredi 18 juillet 2008 19:25:54 Alain Durand, vous avez écrit :
> outside. Mixing ULA & GUA can have complex consequences, and again
> generates service call.

Yeah. Broken RFC3484 implementations will do just that. But all nodes (broken 
and non-broken RFC3484 implementations alike) will *break* without ULA, until 
we have *instantaneous* 100%-reliable and 100%-available upstream connections 
(which we will NEVER have). Without this, the network will simply not work 
until the ISP connection is established (if ever), which is a total 
non-starter. Therefore, it seems like a total non-question that ULA is the 
way to go.

> first, no ULA are generated. Which leads to confusing situation depending
> on whether the customer turns its modem on before or after its CPE.

You may have a point here.

> is available and immediately renumber to GUA when those are acquired.

And break existing connections on the local network? Total no go.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 11:14:38 -0400

Remi and Alain,

It's a very general statement to refer to broken RFC3484 implementations and I agree with that sentiment.  However, please note that our source address selection behavior for ULA and GUA coexisting on the LAN interface is really simple - odds of broken CPE Router implementations are less.  We are pointing to Rule#2 in RFC3484 for scope comparison.  Here is some relevant text from our draft:

[After this process, every LAN interface has a link-local unicast address, a ULA, and a global unicast address (GUA). Therefore, the interface has to apply source address selection to determine which address to use as a source for outgoing packets. Since the GUA has a larger scope than the link-local address, or the ULA (rule #2 of [RFC3484], the GUA will be used as a source address of outgoing packets that are not subject to rule #1.].

Also, if ULA is not used, what choice does one have to configure an IPv6 address on the CPE Router for manual configuration in a standalone CPE Router?

Thanks.

Hemant 

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 10:58 AM
To: Alain Durand
Cc: Hemant Singh (shemant); [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

> consequences, and again generates service call.

Yeah. Broken RFC3484 implementations will do just that. But all nodes (broken and non-broken RFC3484 implementations alike) will *break* without ULA, until we have *instantaneous* 100%-reliable and 100%-available upstream connections (which we will NEVER have). Without this, the network will simply not work until the ISP connection is established (if ever), which is a total non-starter. Therefore, it seems like a total non-question that ULA is the way to go.

> Also, if I read the text correctly, if the WAN interface gets 
> configured first, no ULA are generated. Which leads to confusing 
> situation depending on whether the customer turns its modem on before or after its CPE.

> else is available and immediately renumber to GUA when those are acquired.

--
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jul 2008 11:21:22 -0400

The only time the CPE router needs to use GUA is if it has never  
received a delegated prefix.  Prefix delegation uses the same leasing  
mechanism as address assignment; if the WAN interface on the CPE  
router is not up, the CPE router can still use the previously  
delegated prefix on the subscriber network.

So, as long as the CPE router has been connected to the ISP network at  
least once and has obtained a delegated prefix, there is no need for  
GUA.  To avoid unnecessary complexity, I would strongly recommend that  
the CPE router be required to complete an initial prefix delegation  
operation when first connected to the ISP before enabling any  
downstream interfaces.  Once that prefix delegation takes place, it is  
immaterial whether the LAN or WAN interface comes up first.

This discussion brings up the problem of subscriber network operation  
- is it an explicit goal of this document that the subscriber network  
be able to operate even if the WAN interface is not up?  What are the  
expectations for that unconnected operation and what services must the  
CPE router provide to meet those expectations?

According to the spec, the requesting router can only use the  
delegated prefix until the lease on the prefix expires.  We hadn't  
thought about relaxing that restriction to allow the requesting router  
to continue to use the delegated prefix until it has a WAN connection  
back to the delegating router.

- Ralph

On Jul 21, 2008, at Jul 21, 2008,10:57 AM, Rémi Denis-Courmont wrote:

>> complexity
>> configured
>> depending
>> nothing else

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 11:39:54 -0400

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, July 21, 2008 11:21 AM
To: Rémi Denis-Courmont
Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant); [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

> The only time the CPE router needs to use GUA is if it has never received a delegated prefix.  

Huh? Did you mean to say ULA?  Anyhow, the rest of your discussion does not map to the problem at hand.  Our problem is that I have bought this standalone CPE router from Best Buy (in the U.S.) and now I want to configure it at home via the web for the first time.  I have still not connected the router to the SP WAN.  I just connect an Ethernet cable between the CPE Router LAN interface and my PC and power up the router.  Now I need to configure the router via the web.  Initially we had suggested to use link-local address of the LAN interface to access the router from the web.  But Remi said that needs the full network name interface configuration in some browsers (we didn't need that in our test at Cisco) and also the access has some non-compliance with HTTP.  So then we said, we'll use a ULA.  At this juncture of the router operation/configuration, the router doesn't have any GUA.  A lot of folks in private emails to us have agreed to supporting ULA on the LAN interface(s) of the CPE Router.  We really don't think a coexisting ULA with GUA on the LAN in a problem for any data forwarding or source address selection.

We have one solution using ULA.  If a better solution is available for the problem described above, we are open to it.

Thanks.

Hemant

> Prefix delegation uses the same leasing mechanism as address assignment; if the WAN interface on the CPE router is not up, the CPE router can still use > the previously delegated prefix on the subscriber network.
> 
> So, as long as the CPE router has been connected to the ISP network at least once and has obtained a delegated prefix, there is no need for GUA.  To 
> avoid unnecessary complexity, I would strongly recommend that the CPE router be required to complete an initial prefix delegation operation when first 
> connected to the ISP before enabling any downstream interfaces.  Once that prefix delegation takes place, it is immaterial whether the LAN or WAN 
> interface comes up first.
> 
> - is it an explicit goal of this document that the subscriber network be able to operate even if the WAN interface is not up?  What are the expectations > for that unconnected operation and what services must the CPE router provide to meet those expectations?
> 
> According to the spec, the requesting router can only use the delegated prefix until the lease on the prefix expires.  We hadn't thought about relaxing > that restriction to allow the requesting router to continue to use the delegated prefix until it has a WAN connection back to the delegating router.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jul 2008 11:49:41 -0400

Sorry; yes, please s/GUA/ULA>

The discussion is not irrelevant.  I've seen references in the thread  
to generically enabling the LAN interface before the WAN interface.   
One of the points I explained in my e-mail is that *once the CPE has  
received a prefix* the order of interface enabling is irrelevant.

I also explicitly discussed the corner case you describe.  I don't  
understand why we want to add complexity to allow the customer to  
configure the CPE router before connecting to the WAN.  Once you  
understand that the CPE router can retain the delegated prefix, there  
is no point to worrying about ULA and then renumbering for global  
addresses.  Simply require that the CPE router connect to the WAN long  
enough to get a delegated prefix and then allow the subscriber to do  
any customized config.

- RAlph

On Jul 21, 2008, at Jul 21, 2008,11:39 AM, Hemant Singh (shemant) wrote:

>> received a delegated prefix.
>
> Huh? Did you mean to say ULA?  Anyhow, the rest of your discussion  
> does not map to the problem at hand.  Our problem is that I have  
> bought this standalone CPE router from Best Buy (in the U.S.) and  
> now I want to configure it at home via the web for the first time.   
> I have still not connected the router to the SP WAN.  I just connect  
> an Ethernet cable between the CPE Router LAN interface and my PC and  
> power up the router.  Now I need to configure the router via the  
> web.  Initially we had suggested to use link-local address of the  
> LAN interface to access the router from the web.  But Remi said that  
> needs the full network name interface configuration in some browsers  
> (we didn't need that in our test at Cisco) and also the access has  
> some non-compliance with HTTP.  So then we said, we'll use a ULA.   
> At this juncture of the router operation/configuration, the router  
> doesn't have any GUA.  A lot of folks in private emails to us have  
> agreed to supporting ULA on the LAN interface(s) of the CPE Router.   
> We really don't think a coexisting ULA with GUA on the LAN in a  
> problem for any data forwarding or source address selection.
>
> We have one solution using ULA.  If a better solution is available  
> for the problem described above, we are open to it.
>
> Thanks.
>
> Hemant
>
>> Prefix delegation uses the same leasing mechanism as address  
>> assignment; if the WAN interface on the CPE router is not up, the  
>> CPE router can still use > the previously delegated prefix on the  
>> subscriber network.
>>
>> So, as long as the CPE router has been connected to the ISP network  
>> at least once and has obtained a delegated prefix, there is no need  
>> for GUA.  To
>> avoid unnecessary complexity, I would strongly recommend that the  
>> CPE router be required to complete an initial prefix delegation  
>> operation when first
>> connected to the ISP before enabling any downstream interfaces.   
>> Once that prefix delegation takes place, it is immaterial whether  
>> the LAN or WAN
>> - is it an explicit goal of this document that the subscriber  
>> network be able to operate even if the WAN interface is not up?   
>> What are the expectations > for that unconnected operation and what  
>> services must the CPE router provide to meet those expectations?
>>
>> thought about relaxing > that restriction to allow the requesting  
>> router to continue to use the delegated prefix until it has a WAN  
>> connection back to the delegating router.
>
>> - Ralph
>
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 11:57:33 -0400

I repeat myself. I am only discussing the case when the CPE Router is powered up without connecting the router WAN interface to the SP.  This is also the first time the CPE Router is powered up.  Further this is NOT a corner case.  Moreover, all IPv4 home router customers are used to one stable private IPv4 address to access their say, Linksys router, no matter when and what global IPv4 address gets assigned to the WAN interface.  Why not use one ULA for the same purpose in IPv6?  With your proposal, if the WAN GUA is used to configure the CPE Router, that GUA may change over time and now the user has to remember a new GUA. 

Sorry, I don't think this user experience should be brushed away for IPv6.

Hemant

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, July 21, 2008 11:50 AM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); Rémi Denis-Courmont; Alain Durand; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

The discussion is not irrelevant.  I've seen references in the thread  
to generically enabling the LAN interface before the WAN interface.   
One of the points I explained in my e-mail is that *once the CPE has received a prefix* the order of interface enabling is irrelevant.

I also explicitly discussed the corner case you describe.  I don't understand why we want to add complexity to allow the customer to configure the CPE router before connecting to the WAN.  Once you understand that the CPE router can retain the delegated prefix, there is no point to worrying about ULA and then renumbering for global addresses.  Simply require that the CPE router connect to the WAN long enough to get a delegated prefix and then allow the subscriber to do any customized config.

- RAlph

On Jul 21, 2008, at Jul 21, 2008,11:39 AM, Hemant Singh (shemant) wrote:

> Cc: Ralph Droms (rdroms); Alain Durand; Hemant Singh (shemant); 
> [email-masked] ; Wes Beebee (wbeebee)
> power up the router.  Now I need to configure the router via the web.  
> Initially we had suggested to use link-local address of the LAN 
> interface to access the router from the web.  But Remi said that needs 
> the full network name interface configuration in some browsers (we 
> didn't need that in our test at Cisco) and also the access has
> We have one solution using ULA.  If a better solution is available for 
> the problem described above, we are open to it.
>
> Thanks.
>
> Hemant
>
>> assignment; if the WAN interface on the CPE router is not up, the CPE 
>> router can still use > the previously delegated prefix on the 
>> subscriber network.
>>
>> for GUA.  To avoid unnecessary complexity, I would strongly recommend 
>> that the CPE router be required to complete an initial prefix 
>> delegation operation when first
>> Once that prefix delegation takes place, it is immaterial whether the 
>> LAN or WAN interface comes up first.
>>
>> Yeah. Broken RFC3484 implementations will do just that. But all nodes 
>> (broken and non-broken RFC3484 implementations alike) will *break* 
>> without ULA, until we have *instantaneous* 100%-reliable and 
>> 100%-available upstream connections (which we will NEVER have). 
>> Without this, the network will simply not work until the ISP 
>> connection is established (if ever), which is a total non-starter. 
>> Therefore, it seems like a total non-question that ULA is the way to 
>> go.
>>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jul 2008 12:23:20 -0400

Perhaps we could have a more constructive conversation about solutions  
if we had a detailed description of the requirements for subscriber  
network and device operation.

Certainly assigning both ULA and GUA prefixes across the subscriber  
network is doable, at the cost of extra complexity and the assumption  
that RFC 3484 will actually .  Use of ULA will give a stable address -  
but that stable address is only useful in the unlikely case the home  
network operator actually enters the IPv6 address for the gateway  
instead of using DNS or other naming.

And, it's up to the ISP to provide global prefix stability...

- Ralph

On Jul 21, 2008, at Jul 21, 2008,11:57 AM, Hemant Singh (shemant) wrote:

> I repeat myself. I am only discussing the case when the CPE Router  
> is powered up without connecting the router WAN interface to the  
> SP.  This is also the first time the CPE Router is powered up.   
> Further this is NOT a corner case.  Moreover, all IPv4 home router  
> customers are used to one stable private IPv4 address to access  
> their say, Linksys router, no matter when and what global IPv4  
> address gets assigned to the WAN interface.  Why not use one ULA for  
> the same purpose in IPv6?  With your proposal, if the WAN GUA is  
> used to configure the CPE Router, that GUA may change over time and  
> now the user has to remember a new GUA.
>
> understand that the CPE router can retain the delegated prefix,  
> there is no point to worrying about ULA and then renumbering for  
> global addresses.  Simply require that the CPE router connect to the  
> WAN long enough to get a delegated prefix and then allow the  
> subscriber to do any customized config.
>
> - RAlph
>
>> for
>>> CPE
>>> the

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 12:43:59 -0400

Ralph,

Yes, we can continue the discussion.  Also, by definition a standalone CPE Router is not expected to be managed by the SP - so relying on a GUA from the SP kind of goes against the philosophy of the device.  Folks on the CPE Router thread have been arguing as one voice that the standalone CPE Router should be able to work for configuration without any access to the SP. 

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

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, July 21, 2008 12:23 PM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi Denis-Courmont; Alain Durand; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

Perhaps we could have a more constructive conversation about solutions if we had a detailed description of the requirements for subscriber network and device operation.

Certainly assigning both ULA and GUA prefixes across the subscriber network is doable, at the cost of extra complexity and the assumption that RFC 3484 will actually .  Use of ULA will give a stable address - but that stable address is only useful in the unlikely case the home network operator actually enters the IPv6 address for the gateway instead of using DNS or other naming.

- Ralph

On Jul 21, 2008, at Jul 21, 2008,11:57 AM, Hemant Singh (shemant) wrote:

> I repeat myself. I am only discussing the case when the CPE Router is 
> powered up without connecting the router WAN interface to the
> customers are used to one stable private IPv4 address to access their 
> say, Linksys router, no matter when and what global IPv4 address gets 
> assigned to the WAN interface.  Why not use one ULA for the same 
> purpose in IPv6?  With your proposal, if the WAN GUA is used to 
> configure the CPE Router, that GUA may change over time and now the 
> user has to remember a new GUA.
>
> Cc: Ralph Droms (rdroms); Rémi Denis-Courmont; Alain Durand; 
>> bought this standalone CPE router from Best Buy (in the U.S.) and now 
>> I want to configure it at home via the web for the first time.
>> interface to access the router from the web.  But Remi said that 
>>> for GUA.  To avoid unnecessary complexity, I would strongly 
>>> recommend that the CPE router be required to complete an initial 
>>> prefix delegation operation when first connected to the ISP before 
>>> enabling any downstream interfaces.
>>> the LAN or WAN interface comes up first.
>>>
>>> Yeah. Broken RFC3484 implementations will do just that. But all 
>>> nodes (broken and non-broken RFC3484 implementations alike) will 
>>> *break* without ULA, until we have *instantaneous* 100%-reliable and 
>>>> nothing else is available and immediately renumber to GUA when 
>>>> those are acquired.
>>>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jul 2008 16:02:28 -0400

Do you acknowledge that once the CPE router has obtained a delegated  
prefix it is no longer necessary for the WAN interface on the CPE  
router to be enabled for that delegated prefix to be used on the  
subscriber network?

We'll have to agree to disagree about whether configuring the CPE  
router prior to any SP access is a corner case.

- Ralph

On Jul 21, 2008, at Jul 21, 2008,12:43 PM, Hemant Singh (shemant) wrote:

> Ralph,
>
> Yes, we can continue the discussion.  Also, by definition a  
> standalone CPE Router is not expected to be managed by the SP - so  
> relying on a GUA from the SP kind of goes against the philosophy of  
> the device.

>  Folks on the CPE Router thread have been arguing as one voice that  
> the standalone CPE Router should be able to work for configuration  
> without any access to the SP.
>
>
> 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
>
> Cc: Ralph Droms (rdroms); Mark Townsley (townsley); Jimmy Chuang  
> (cchuang); Rémi Denis-Courmont; Alain Durand; [email-masked];  
> Wes Beebee (wbeebee)
> Perhaps we could have a more constructive conversation about  
> solutions if we had a detailed description of the requirements for  
> subscriber network and device operation.
>
> network is doable, at the cost of extra complexity and the  
> assumption that RFC 3484 will actually .  Use of ULA will give a  
> stable address - but that stable address is only useful in the  
> unlikely case the home network operator actually enters the IPv6  
> address for the gateway instead of using DNS or other naming.
>
>>> now
>>> web.

---

From: Antonio Querubin <[email-masked]>
Date: Mon, 21 Jul 2008 11:29:17 -1000 (HST)

On Mon, 21 Jul 2008, Ralph Droms wrote:

> This discussion brings up the problem of subscriber network operation - is it 
> an explicit goal of this document that the subscriber network be able to 
> operate even if the WAN interface is not up?  What are the expectations for 
> that unconnected operation and what services must the CPE router provide to 
> meet those expectations?

I suspect I'm over-simplifying but this comes down to whether the 'dentist 
office' operation needs to continue operations.  I think it does.  Should 
the CPE router even send RAs or any hint of it's presence until the WAN 
connection is confirmed to be working?  On one hand, a CPE router with a 
single logical LAN interface can be designed to provide virtual presence 
of the SP connection iff connectivity through the WAN is available.  And 
that can be predicated on whether the CPE router is able to obtain or 
sense some kind of connectivity from the SP.  Once that single LAN/WAN 
behaviour is pinned down, then what remains to be determined is how 
multiple LAN interfaces in a CPE router should interact if the WAN or 
upstream connectivity is down.

> According to the spec, the requesting router can only use the delegated 
> prefix until the lease on the prefix expires.  We hadn't thought about 
> relaxing that restriction to allow the requesting router to continue to use 
> the delegated prefix until it has a WAN connection back to the delegating 
> router.

Difficult to predict how this will play out but if the design goal of this 
draft is a hands-off CPE router, it's hard to see how connectivity between 
multiple LANs in the subscriber's network can be maintained reliably 
without some kind of forced persistence behaviour.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 19:10:40 -0400

Antonio and Ralph,

Even if the CPE Router WAN interface is down, one does expect LAN services between devices in the home to work.  My printer server is connected to one LAN interface while few PC's in my home are connected to another LAN interface.  Therefore IPv6 data forwarding and routing should continue to work in the home.  Only use of ULA then provides this continued operation in the home.  Also, a home router always includes a bridge internally (it has been mentioned in the mailer) that is always on if the device is powered up.  The LAN of the CPE router is connected to this bridge.  LAN can totally continue to work in the home even if WAN is down.

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 5:29 PM
To: Ralph Droms (rdroms)
Cc: Rémi Denis-Courmont; Alain Durand; Hemant Singh (shemant); [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

> CPE router provide to meet those expectations?

I suspect I'm over-simplifying but this comes down to whether the 'dentist office' operation needs to continue operations.  I think it does.  Should the CPE router even send RAs or any hint of it's presence until the WAN connection is confirmed to be working?  On one hand, a CPE router with a single logical LAN interface can be designed to provide virtual presence of the SP connection iff connectivity through the WAN is available.  And that can be predicated on whether the CPE router is able to obtain or sense some kind of connectivity from the SP.  Once that single LAN/WAN behaviour is pinned down, then what remains to be determined is how multiple LAN interfaces in a CPE router should interact if the WAN or upstream connectivity is down.

> back to the delegating router.

Difficult to predict how this will play out but if the design goal of this draft is a hands-off CPE router, it's hard to see how connectivity between multiple LANs in the subscriber's network can be maintained reliably without some kind of forced persistence behaviour.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jul 2008 12:58:50 +1200

Regardless of whether the WAN interface is up or down,
it's a normal and legitimate use of a ULA prefix to
run it in parallel with a GUA prefix. So there is never,
ever, any need to withdraw the ULA prefix once it has
been created (as you say, it's as stable as the
RFC1918 prefix that most CPEs use today). And supporting
multiple prefixes is standard in every IPv6 node, so
there isn't actually any scope to debate this.

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 19:10:40 -0400

Antonio and Ralph,

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 5:29 PM
To: Ralph Droms (rdroms)
Cc: Rémi Denis-Courmont; Alain Durand; Hemant Singh (shemant); [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

Antonio Querubin
whois:  AQ7-ARIN

---

From: [email-masked]
Date: Mon, 21 Jul 2008 23:11:56 -0600

Hemant Singh (shemant) writes: 

> I repeat myself. I am only discussing the case when the CPE Router is powered up without connecting the router WAN interface to the SP.  This is also the first time the CPE Router is powered up.  Further this is NOT a corner case.  Moreover, all IPv4 home router customers are used to one stable private IPv4 address to access their say, Linksys router, no matter when and what global IPv4 address gets assigned to the WAN interface. 

I think this describes the confusion here. You are looking for a default IP 
address for the device so that users can connect to it for configuring it? 
In IPv4 there is usually a default RFC 1918 address that will do just this 
function in order to enable configuration. So would it meet your needs if we 
used something like ::192:168:0:1 for the default address if it is used via 
the Ethernet or wireless (802.11x) port? 

\

---

From: [email-masked]
Date: Mon, 21 Jul 2008 23:20:40 -0600

Ralph Droms writes: 

> prefix it is no longer necessary for the WAN interface on the CPE  router 
> to be enabled for that delegated prefix to be used on the  subscriber 
> network? 
> 
> We'll have to agree to disagree about whether configuring the CPE  router 
> prior to any SP access is a corner case. 
> 

Ralph, I think I understand what is being asked for here.  Think of the 
Cisco ONS 15327 with the default IP address of 192.1.0.2 or the Cisco 
AIR-WGB350 with the default IP address of 10.0.0.1. 

In both cases it is possible to connect to the router via an Ethernet (not 
console) port using a default IP address to configure the router via a 
browser or telnet session. 

I suspect that this is the requirement that is being misunderstood here. In 
my previous e-mail (today) I half jokingly suggested ::192.168.0.1 as an 
example. For manufacturer consistency we may want to look at using 
::192:1:0:2 for the ONS 1537 and ::10:0:0:1 for the AIR-WGB350. 

Eric

---

From: "Bonness, Olaf" <[email-masked]>
Date: Tue, 22 Jul 2008 08:38:51 +0200

> On Monday, July 21, 2008 10:02 PM Ralph Droms wrote:
>
> ...
> 

In my eyes the CPE should be able to connect devices in the several links of the customer LAN - also in the case that it is not yet connected via its WAN interface to the SP. Hence I think that ULAs are needed for the LAN site of the CPE.

My 2 cent.
	Olaf

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 22 Jul 2008 09:56:55 +0300

> router prior to any SP access is a corner case.

Setting up the DSL upstream can be a rather slow procedure if the signal level 
on the line is close to the technical limits. Cable connections can sometime 
just fail... and when they get up again, they might renumber. And what if the 
upstream connection is down for so long that the GUA prefix times out?

As far as I can tell, provisioning a ULA always, regardless of the GUA is 
actually simpler and less failure-prone.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 10:56:45 -0400

Hemant,

I have no problem using ULA *in*the*absence*of* GUA. I understand that the
network has to be workable in the absence of upstream connectivity.

What I'd like to see is ULA being renumbered into GUA as soon as those
becomes available.

Brian is suggesting to have a mode where the user may also want to keep the
ULA *after* GUA are acquired, I'm fine with that as long as it is not the
default config.

   - Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 11:19:07 -0400

Alain,

What is the concern if ULA is permanent and always present on the CPE
Router?  Till we see a strong justification for not having this mode of
operation on the router, we will not change the draft.  However, we do
collect input like yours (it's totally appreciated as well) and we will
keep it in mind to track for proper justification.

I have heard source-address selection issues but they are not sufficient
justification.  The SP also does not see these ULA in their network -
granted some day in future, the SP may, but then if ULA changes that
much to be globally routable, then the CPE Router specification also has
to change. 

The ULA has additional justification to be permanent.  The user at home
does not want to be nickel and dimed by the SP who can say, I will dole
out only one IA_PD to your home and that IA_PD is /56.  The ULA has a
much shorter prefix of /48 to serve the home network better. I want
devices in my home to have permanent IPv6 addresses - ULA gives me that,
GUA will not (GUA can be renumbered).  Permanent ULA in IPv6 is also
what the user is used to from IPv4 and it RFC1918 addresses - thanks
Brian Carpenter.

You see, we don't want to add another knob to the CPE Router or any new
state machine unless the knob or state machine is justified.  Please
show us a case where concurrent ULA and GUA on the CPE Router totally
breaks something and causes a major problem. 

Thanks.

Hemant

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2008 10:57 AM
To: Hemant Singh (shemant); Brian E Carpenter
Cc: [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

Hemant,

I have no problem using ULA *in*the*absence*of* GUA. I understand that
the network has to be workable in the absence of upstream connectivity.

Brian is suggesting to have a mode where the user may also want to keep
the ULA *after* GUA are acquired, I'm fine with that as long as it is
not the default config.

   - Alain.

> Router at home and the LAN interface(s) of the router will be up first

> - the user hasn't connected the WAN port yet to the broadband network.
> web.  That is why the ULA will be used.  We have also said in our 
> draft that manual configuration is out of scope of our draft - 
> therefore we are not worried about details like how does the user get 
> to know the ULA prior to logging on to the CPE Router over the web 
> using this ULA.  If need be, we can also work on such details but 
> there is no dispensing with ULA.  I too like Brian's suggestion of 
> once per factory-reset and further I prefer a well-known ULA address 
> publishes apriori in the CPE Router manuals for the user to use that 
> address to configure the CPE Router.  After configuration, any other 
> ULA may be generated and the router reset to use the new ULA and
associated ULA prefix(es).
> draft.  See my other comments about WAN init first model also 
> complying with CableLab docsis 3.0 standards.
> 
> Hemant
> 
>> to

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 22 Jul 2008 18:39:07 +0300

> ULA *after* GUA are acquired, I'm fine with that as long as it is not the

Renumbering break applications. Maybe ISPs don't care less about the user LAN 
working properly. But users and CPE vendors do care.

My IPv4 file shares, jobs-being-printed and UPnP AV streams don't break when 
my IPv4 NAT router gets the WAN interface (re)configured, because the LAN 
IPv4 address do not change through the process. That's one of the few merits 
of NAT. Like it or not, most LAN applications require/assume stable 
addresses. Hence *constant* ULA addresses are needed on the LAN side 
all_the_time *regardless* of the state and state changes on the WAN side.

Not only that, but I fail to see the problem with ULA. The extra complexity in 
supporting ULA on the CPE is a lot less than the extra complexity of 
rewriting all LAN applications and transport protocols (including TCP...) to 
handle unstable addresses.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 11:39:44 -0400

> non-starter. Therefore, it seems like a total non-question that ULA is the

I have said a couple times, I have no objection to using ULA when nothing
else is available. 

> And break existing connections on the local network? Total no go.

Simple use short prefix lifetime for ULA and deprecate. Normal renumbering
procedure.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 11:43:43 -0400

On 7/21/08 11:57 AM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> I repeat myself. I am only discussing the case when the CPE Router is powered
> up without connecting the router WAN interface to the SP.  This is also the
> first time the CPE Router is powered up.  Further this is NOT a corner case.
> Moreover, all IPv4 home router customers are used to one stable private IPv4
> address to access their say, Linksys router, no matter when and what global
> IPv4 address gets assigned to the WAN interface.  Why not use one ULA for the
> same purpose in IPv6?  With your proposal, if the WAN GUA is used to configure
> the CPE Router, that GUA may change over time and now the user has to remember
> a new GUA.
> 

I sure hope you are not expecting the customer to remember or type a well
know IPv6 ULA address to configure the home router...
There need to be a dynamic discovery mechanism, a la Apple bonjour.

   - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 11:48:11 -0400

On 7/21/08 12:43 PM, "Hemant Singh (shemant)" <[email-masked]> 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.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 11:50:17 -0400

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2008 11:44 AM
To: Hemant Singh (shemant); Ralph Droms (rdroms); Mark Townsley (townsley); Jimmy Chuang (cchuang)
Cc: Rémi Denis-Courmont; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

On 7/21/08 11:57 AM, "Hemant Singh (shemant)" <[email-masked]> wrote:

>> powered up without connecting the router WAN interface to the SP.  
>> This is also the first time the CPE Router is powered up.  Further this is NOT a corner case.
>> Moreover, all IPv4 home router customers are used to one stable 
>> private IPv4 address to access their say, Linksys router, no matter 
>> when and what global
>> IPv4 address gets assigned to the WAN interface.  Why not use one ULA 
>> for the same purpose in IPv6?  With your proposal, if the WAN GUA is 

> I sure hope you are not expecting the customer to remember or type a well know IPv6 ULA address to configure the home router...

>  - Alain.

Heck no!  My good colleague in Tony Hain already pointed us to http://en.wikipedia.org/wiki/Zeroconf.  We envision every CPE Router to have a unique ULA but the router will be accessed by a URL like http://linksyslocal.

Hemant

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 12:00:34 -0400

On 7/22/08 1:11 AM, "[email-masked]" <[email-masked]>
wrote:

>> IPv4 address gets assigned to the WAN interface.
> 

Eric,

You are right in the analysis of the confusion. However, I think we should
move away from such things as well know IP addresses and use some form of
service discovery protocol instead.

  - Alain.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 13:17:25 -0400

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:[email-masked]] 
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; [email-masked]; 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)" <[email-masked]> wrote:

> 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.

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 13:25:05 -0400

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)" <[email-masked]> 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
> 
> Multi-party communications *with* address referral do not work in the general
> case in such a mixed environment, regardless of default address selection.
> 
>   - Alain.
> 
>

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 22 Jul 2008 09:50:28 -1000 (HST)

> working properly. But users and CPE vendors do care.

*Ahem* ISPs do care.  For the intended mass-market of this CPE router, the 
end-customer probably has no full-time IT expert.  Guess who they call 
first when things break?  The consultant who costs money?  Nephew Tim who 
might have a real day job?  Or the ISP support line?

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 17:01:43 -0400

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:[email-masked]] 
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; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

Hemant,

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)" <[email-masked]> 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
> 
> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi 
> Denis-Courmont; [email-masked]; Wes Beebee (wbeebee)
>> 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.
> 
> general case in such a mixed environment, regardless of default address selection.
> 
>   - Alain.
> 
>

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 17:10:07 -0400

Hemant,

Thank you for looking into this.
The issue is that C's connection to B may have to wait for TCP timeout,
which is 3 min. This is long. Too long.

  - Alain.

On 7/22/08 5:01 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> 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.
> 
> 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
> 
> 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.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 17:35:02 -0400

Sure thing.  But I would expect that node C would receive the ICMPv6 Destination Unreachable before TCP times out, wouldn't you?

Hemant

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2008 5:10 PM
To: Hemant Singh (shemant); Ralph Droms (rdroms)
Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi Denis-Courmont; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

Hemant,

Thank you for looking into this.
The issue is that C's connection to B may have to wait for TCP timeout, which is 3 min. This is long. Too long.

  - Alain.

On 7/22/08 5:01 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> 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.
> 
> 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.
> 
> 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
> 
> 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.
>

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 17:43:35 -0400

This has not been my experience using multiple addresses. You may want to
read some of my earlier work:

http://www.ietf.org/rfc/rfc4943.txt?number=4943
http://www.watersprings.org/pub/id/draft-roy-v6ops-v6onbydefault-01.txt

  - Alain.

On 7/22/08 5:35 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> Sure thing.  But I would expect that node C would receive the ICMPv6
> Destination Unreachable before TCP times out, wouldn't you?
> 
> Hemant
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 18:00:42 -0400

I see.  Thanks for sharing the experience.  But the TCP issue mentioned in section 3.2 of RFC4943 says the host is in a router-less network.  Host C in the example you gave sits in a routed network because host C is behind the CPE Router.  Does that make any difference?  

Anyhow, for your example since C and B sit in different home, their ULA and GUA prefixes are off-link to each other, so why would host C issue an address resolution?

Hemant 

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2008 5:44 PM
To: Hemant Singh (shemant); Ralph Droms (rdroms)
Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi Denis-Courmont; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

This has not been my experience using multiple addresses. You may want to read some of my earlier work:

  - Alain.

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 22 Jul 2008 18:05:29 -0400

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: [email-masked] [mailto:[email-masked]] 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; [email-masked]; Wes Beebee (wbeebee)
Subject: RE: New (-02) version of IPv6 CPE Router draft is available for review

Alain,

Thanks.

Hemant

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
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; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

Hemant,

  - Alain.

> general case in such a mixed environment, regardless of default address selection.

*****

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

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 18:08:09 -0400

On 7/22/08 6:00 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> I see.  Thanks for sharing the experience.  But the TCP issue mentioned in
> section 3.2 of RFC4943 says the host is in a router-less network.  Host C in
> the example you gave sits in a routed network because host C is behind the CPE
> Router.  Does that make any difference?
> 
> Anyhow, for your example since C and B sit in different home, their ULA and
> GUA prefixes are off-link to each other, so why would host C issue an address
> resolution?

The on-link/off-link is just an example to illustrate the larger problem
that trying multiple addresses that will fail first can introduce long
delays.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 18:15:04 -0400

[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" <[email-masked]> 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
> 
> 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
> 
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 18:33:36 -0400

I don't believe apps have to know topology if apps receive a GUA and a ULA.  The app has to just ignore the ULA.

I will continue to discuss this lot with my internal Cisco colleagues and see what we can do.  Anyone else on the mailer is welcome to chime in.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alain Durand
Sent: Tuesday, July 22, 2008 6:15 PM
To: [email-masked]
Subject: Permanent ULA support in home networking (Re: New (-02) version of IPv6 CPE Router draft is available for review)

[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" <[email-masked]> 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
> 
> 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
> 
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 18:31:10 -0400

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Tuesday, July 22, 2008 6:08 PM
To: Hemant Singh (shemant); Ralph Droms (rdroms)
Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rémi Denis-Courmont; [email-masked]; Wes Beebee (wbeebee)
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for review

On 7/22/08 6:00 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> I see.  Thanks for sharing the experience.  But the TCP issue 
> mentioned in section 3.2 of RFC4943 says the host is in a router-less 
> network.  Host C in the example you gave sits in a routed network 
> because host C is behind the CPE Router.  Does that make any difference?
> 
> Anyhow, for your example since C and B sit in different home, their 
> ULA and GUA prefixes are off-link to each other, so why would host C 
> issue an address resolution?

>> The on-link/off-link is just an example to illustrate the larger problem that trying multiple addresses that will fail first can introduce long delays.

>>  - Alain.

Ah, OK, I understand you and also since I read the last para of section 3.2 of your draft.  To nip this problem in the bud, as I said before, let the host app fix its bug to first not send ULA in "address info" to another host and also if any host app receives a ULA and GUA, the app should ignore the ULA.

Hemant

---

From: Alain Durand <[email-masked]>
Date: Tue, 22 Jul 2008 18:38:33 -0400

> The app has to just ignore the ULA.

Exactly my point. Apps need to be made aware of the difference between ULA &
GUA, which is what the ULA proponents have been saying all along will not be
necessary.

  - Alain.

---

From: [email-masked]
Date: Wed, 23 Jul 2008 00:01:22 +0000

you know, this outcome (ULA == GUA) was predicted from the 
	begining of the ULA emergence.  and the many assurances that
	*never* would ULA's *ever*  become GUAs are hollow.

--bill

On Tue, Jul 22, 2008 at 06:15:04PM -0400, Alain Durand wrote:
> > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi Denis-Courmont;
> > [email-masked]; Wes Beebee (wbeebee)
> > Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi Denis-Courmont;
> > [email-masked]; Wes Beebee (wbeebee)
> >> Cc: Mark Townsley (townsley); Jimmy Chuang (cchuang); Rimi

---

From: [email-masked]
Date: Wed, 23 Jul 2008 02:26:12 -0600

> service discovery protocol instead.

Alain,
The problem with addressing this problem with a service discovery protocol 
is that it will not meet the requirement of what to do when the router is 
the only service and is in need of initial configuration. In the past Cisco 
mandated that the console port was the way to do this while others have gone 
for a direct connect USB, but in a wireless situation there is no physical 
port to connect to while configuring the CPE. 

So unless you want to replace a "well known IP address" with a "well known 
ULA" then we need to find another solution. Or are you proposing that we 
make the discovery protocol enable a "find and configure CPE/router" option? 
If so I have a problem with the security implications of such a wide open 
configuration requirement. 

Eric

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 23 Jul 2008 12:35:30 +0200

On Tue, 22 Jul 2008 18:15:04 -0400, Alain Durand

<[email-masked]> wrote:

> [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

> especially in referrals.

Avoiding literal addresses is orthogonal to using ULA. Human beings will

not remember ULA addresses, neither GUA addresses. In both cases, a local

DNS server, or a multicast discovery system will be required. In the mean

time, CPE vendors will continue to document http://192.168.0.1 alike as the

way to configure the (dual-stack) CPE.

Same thing with service location. People will use UPnP, Bonjour, SAP or

whatever. There is actually some value in using ULAs here, as the

applications can easily check that this is "Intranet". With GUAs, it is

do-able but more difficult to tell semi-trusted local peers from untrusted

remote ones.

> 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.

Most applications do not do referrals. And those that do... they will need

to have some IPv6 logic _anyway_ (e.g. to discard link-local), know

multicast groups, do AAAA lookups, etc.

Most applications will screw up, especially LANish applications (file

shares, printers, ...) if they need to reconnect. In fact, reconnecting is

typically not a complete solution due to protocol limitations. To the

contrary, enumerating addresses properly is an implementation issue that

does not affect protocol design.

Also, it is fairly typical for LAN applications to start doing discovery

right at boot. Precisely when renumbering from ULA to GUA is likely to

occur and break things up.

-- 

Rémi Denis-Courmont

---

From: [email-masked]
Date: Wed, 23 Jul 2008 02:33:14 -0600

> might have a real day job?  Or the ISP support line? 

Of the choices, my experience says Nephew Tim is first called. People hate 
having to call tech support more than consultants. The long wait, the 
"select 1 for..." menu, etc.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 23 Jul 2008 12:43:06 +0200

On Tue, 22 Jul 2008 18:38:33 -0400, Alain Durand

>> I don't believe apps have to know topology if apps receive a GUA and a

>> ULA. The app has to just ignore the ULA.

> Exactly my point. Apps need to be made aware of the difference between

ULA

> & GUA, which is what the ULA proponents have been saying all along will

not

> be necessary.

That depends how the applications learn the ULA in the first place...

If an application uses referral, it might well be that the rendez-vous

mechanism provides GUA even for on-link hosts, so the application will not

even see the ULA ever and there will be no issues. For an Internet-wide

service, I would expect the application to connect to a global location

server (from/to GUA) and register that source address, the GUA, with the

service.

Conversely, if the service is not intended to work outside of the LAN: it

is OK for my file sharing and printing service to use ULA in referrals

because it is not supposed to work from the outside in the first place.

-- 

Rémi Denis-Courmont

---

From: Alain Durand <[email-masked]>
Date: Wed, 23 Jul 2008 10:15:27 -0400

Eric,

>From a security perspective, what is the difference between:

A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a similar
range, asking people to configure it using http://[10.0.0.1]
B) the same thing using link local address, with the router being configured
using fe80::1 and asking people to configure it using http://[fe80::1]
C) the same replacing link local by ULA
D) having the router advertizing itself as a router using a service
discovery protocol a la Apple Bonjour?

In all those case, a 'bad guy' can easily impersonate the router.

  - Alain.

---

From: [email-masked]
Date: Wed, 23 Jul 2008 09:31:08 -0600

Alain, 

Your example B is exactly what I am suggesting, a it is identical to A in an 
IPV6 world. 

C link local is going to be a new option for people.
D sounds like a problem to me as you don't want to advertise a "come 
configure me" service. This is the one I am most against in my previous 
e-mail. 

The if there is a local address to be connected to (either link local or ULA 
or fixed IP address) then it is possible to fulfill the configuration prior 
to having an IP address from the ISP scenario. 

Thus the "bad guys" who are spoofing would need to both know the address 
(and that works for any fixed predefined address) and admin password (also 
usually a default one until changed). And impersonating the router would be 
meaningless as it is only the initial configuration that I am addressing and 
I doubt that someone would set themselves up hoping to catch a new setup 
that could happen anytime if at all.

---

From: Alain Durand <[email-masked]>
Date: Wed, 23 Jul 2008 11:50:06 -0400

> configure me" service. This is the one I am most against in my previous

Why? I fail to see any more problems with this than with the other
approaches.

  - Alain.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 23 Jul 2008 19:17:00 +0300

Le mercredi 23 juillet 2008 18:31:08 [email-masked], vous avez 
écrit :
> Alain Durand writes:
> >> The problem with addressing this problem with a service discovery
> >> protocol is that it will not meet the requirement of what to do when the
> >> router is the only service and is in need of initial configuration. In
> >> the past Cisco mandated that the console port was the way to do this
> >> while others have gone for a direct connect USB, but in a wireless
> >> situation there is no physical port to connect to while configuring the
> >> CPE.
> >>
> >> So unless you want to replace a "well known IP address" with a "well
> >> known ULA" then we need to find another solution. Or are you proposing
> >> that we make the discovery protocol enable a "find and configure
> >> CPE/router" option? If so I have a problem with the security
> >> implications of such a wide open configuration requirement.
> >
> > Eric,
> >
> > A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a
> > similar range, asking people to configure it using http://[10.0.0.1]
> > B) the same thing using link local address, with the router being
> > configured using fe80::1 and asking people to configure it using
> > http://[fe80::1] C) the same replacing link local by ULA

> Your example B is exactly what I am suggesting, a it is identical to A in
> an IPV6 world.

As already pointed out in this same thread, link-local addresses do NOT work 
in most web browsers, as you need to know which local interface to use - not 
suited at all within a for-dummies installation guide.

ULAs will not fit the bill either because the prefix ought to be 
pseudo-random, and different for each and every shipped box.

GUAs do not fit as they also depend on the customer, and by definition, are 
not available until the CPE has been successfully configured.

Site-local addresses would have worked, but they're now deprecated.

Multicast service discovery does not work because it is not implemented with 
current hosts - if we specify if now, it will be years before it can be used.

So... you're stuck instructing the customer to use the constant IPv4 address. 
That works today and will continue to work for the foreseeable future of 
dual-stack hosts on unmanaged networks.

As much as I believe the CPE ought to provision a permament ULA prefix, I also 
believe the initial configuration argument is completely bogus.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: [email-masked]
Date: Thu, 24 Jul 2008 04:33:40 -0600

> dual-stack hosts on unmanaged networks. 
I agree with your assessment here. 

> believe the initial configuration argument is completely bogus. 

Bogus or not, this seems to be one of the problems that was being addressed 
by this draft. We need to look at 2 things:
1. What is the problem being pointed out and what solutions are available to 
fix it?
2. Is this a big enough problem to be worth our time in addressing. 

You seem to have done a good job on number 1, now the WG needs to decided on 
number 2.

---

From: [email-masked]
Date: Thu, 24 Jul 2008 04:29:24 -0600

> Why? I fail to see any more problems with this than with the other

Having a known address is not the same as advertising it out to anyone that 
is locally connected. Admittedly it is only a short term improvement until 
the fixed address becomes commonly known via the internet, but even then it 
is only a problem if someone comes to the area of a wireless network where 
the security has not been changed from the default. 

Consider the situation as follows:
Person x goes and buys a WiFI router to connect to their DSL link. But prior 
to connecting to the DSL they plug it in to configure it. The only way that 
someone would know to try to configure it would be to see it in their 
available networks and then recognize the brand and to try to connect to the 
default IP address. Vs. Someone sees a new hotspot advertising a "come 
configure me" service. In the first case you need to proactivly go looking 
for things to hack, in the second you are invited in to do so. 

Maybe I am alone on this, but I prefer to make the hacker try harder without 
inviting them inside. 

Eric

---

From: Alain Durand <[email-masked]>
Date: Thu, 24 Jul 2008 07:23:22 -0400

Eric,

The property of well known address is that, well, they are well known. So if
a vendor start to use fe80::1, I guess most vendors will use it and there is
little guesswork to be done.

Now, with service discovery, I would expect that as soon as the device is
configured the first time, some king of security will be put in place, if
only using a password. This can be done before the ISP connection is up. If
the user decide not to use a passwd or any other form of security, well,
this is a different issue.

I have seen this discovery being implemented already: simply try to
configure an Apple airport.

  - Alain.

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 24 Jul 2008 16:06:33 -0400

I'd rather the IETF didn't try to mandate some specific well-known
address for routers, or a service discovery protocol. Personally, since
I "play" with so many different home routers from different
manufacturers, I don't bother trying any well-known address to get to
the UI. I can't remember who uses what. And I hate reading the manual.
There are so many different values in use, that I find it easier to just
run ipconfig / ifconfig and see what my Default Gateway is set to. Put
that in the browser, and I'm at the router UI. 

I do know that if a device has a DSL modem in it, then it is likely to
support the standard domain name specified by the Broadband Forum
(formerly DSL Forum): dsldevice
I expect that to continue.

If there is to be some sort of discovery and then presenting the results
to the user in a friendly manner, then there will need to be an
application that does all this. If there's an application, it probably
doesn't care where the info comes from. Surely somewhere between all the
ND and RA and such, there must be an IPv6 address that can lead an
application to the router, without trying to mandate or recommend
support for some service discovery protocol. I don't need for a device
to advertise that it has an HTTP server at port 80 on a particular IP
address. I just need the device's IP address. 
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alain Durand
Sent: Thursday, July 24, 2008 7:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

Eric,

The property of well known address is that, well, they are well known.
So if
a vendor start to use fe80::1, I guess most vendors will use it and
there is
little guesswork to be done.

Now, with service discovery, I would expect that as soon as the device
is
configured the first time, some king of security will be put in place,
if
only using a password. This can be done before the ISP connection is up.
If
the user decide not to use a passwd or any other form of security, well,
this is a different issue.

  - 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. GA622

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 25 Jul 2008 12:01:46 -0400

Folks,

If every CPE Router has a unique ULA that is mapped to something like
http://homerouter.local via mDNS (as per zeroconf) standards, does that
work for you?  If Barbara doesn't want to even look at the device manual
for the named URL, then should every device vendor use the same URL
which can then be specified in our draft or any other zeroconfg draft?
Just some thoughts.

Thanks.

Hemant
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stark, Barbara
Sent: Thursday, July 24, 2008 4:07 PM
To: Alain Durand; [email-masked]
Cc: [email-masked]
Subject: RE: New (-02) version of IPv6 CPE Router draft is available for
review

I do know that if a device has a DSL modem in it, then it is likely to
support the standard domain name specified by the Broadband Forum
(formerly DSL Forum): dsldevice I expect that to continue.

-----Original Message-----

Eric,

The property of well known address is that, well, they are well known.
So if
a vendor start to use fe80::1, I guess most vendors will use it and
there is little guesswork to be done.

Now, with service discovery, I would expect that as soon as the device
is configured the first time, some king of security will be put in
place, if only using a password. This can be done before the ISP
connection is up.
If
the user decide not to use a passwd or any other form of security, well,
this is a different issue.

  - 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. GA622

---

From: [email-masked]
Date: Fri, 25 Jul 2008 12:23:26 -0600

Stark, Barbara writes: 

> address for routers, or a service discovery protocol. 

Agreed, it is more a methodology than a specific address that I am 
proposing. 

>Personally, since

Problem with this is that there is no default gateway unless you have the 
predefined IP that you are against. Otherwise a new (unconfigured) device 
has no IP addresses to give out via DHCP (v4 or v6) and thus can not reply 
to an IPCONFIG command. In that case the default will be 0::00 or such, and 
will be of little help. 

> I expect that to continue. 

I am not so sure if other devices will have this same type of predefined 
service. 

> address. I just need the device's IP address. 

This makes sense, it is what is behind the getting of that initial address 
that is being discussed.
Eric

---

From: [email-masked]
Date: Fri, 25 Jul 2008 12:35:05 -0600

> configure an Apple airport.

Alain
I fail to see the practical difference between these solutions. My main 
concern is that the majority of users out there are not using Apple type 
logic but Microsoft's version of logic. Therefore a known process or method 
is going to become necessary. Today this is done via known IP addresses per 
brand/model. What you are describing sounds more like finding an available 
hotspot via WiFi.  If this is the consensus that the WG takes that is fine, 
I am just not sure it is the simplest solution to this requirement in all 
cases.
Eric

---

From: [email-masked]
Date: Fri, 25 Jul 2008 12:29:47 -0600

> which can then be specified in our draft or any other zeroconfg draft?
Does this not go back to the known name issue. 

I do not have a problem with it, all I want is a consistent solution that 
will work prior to having an ISP assigned IP address available or a DHCP 
address pool defined.
Eric

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 25 Jul 2008 20:00:31 -0400

Eric,

I did go back and read Remi's email.  Sorry, I have to catch up with
some IETF email.  Yes, it does go back to the problem that Remi raised,
but I don't see a problem with a web browser adding a Bonjour plugin for
mDNS - that may not be asking the user a whole lot.  I do appreciate
Remi's point that many browsers to not have such a plugin.  I and Wes
personally don't like using an IPv4 URL to configure the new IPv6 CPE
Router.  We have to plan for a day "x" years from now when no IPv4 is
provisioned on the device.  We have got to have an IPv6 solution to
configure the device from a web browser.  

Also, when the CPE Router is powered up for the first time, a unique ULA
may be generated by the device that persists for the lifetime of
operation of the device.  This ULA may be mapped to mDNS - I haven't
read the mDNS draft yet to make sure if the protocol allows for a
non-link-local address to be returned in the mDNS response.  I would
think it should be possible.  Also since the ULA is pseudo-random, in
case a user at home discovers a conflict, a knob on the CPE Router can
generate a new ULA.

Hemant

---

From: [email-masked]
Date: Sat, 26 Jul 2008 23:47:08 -0600

Hemant Singh (shemant) writes:
> Remi's point that many browsers to not have such a plugin.  

I am not sure it is in our mandate to require changes in a browser or that 
they support a mDNS plugin. 

> I and Wes

Agreed 

> case a user at home discovers a conflict, a knob on the CPE Router can

See comment above. I am not sure that mandating a change in browser software 
and CPE hardware is the right answer to this requirement.

---

From: David Miles <[email-masked]>
Date: Mon, 28 Jul 2008 08:46:13 +0100

In addition to any dnsext work we should include unicast DNS

Btw, one limitation with mDNS (in its current form) is that it is link- 
local scope - if we anticipate a routed home network we may need to  
feed into the dnsext wg to explore the practicality of service  
discovery across router boundaries. I'd like me iTunes to work within  
the IPv6 home network of the future

-d

On 25/07/2008, at 7:29 PM, [email-masked] wrote:

>> Folks, If every CPE Router has a unique ULA that is mapped to  
>> something like
> I do not have a problem with it, all I want is a consistent solution  
> that will work prior to having an ISP assigned IP address available  
> or a DHCP address pool defined.
> Eric
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Jul 2008 22:33:47 +1200

There wasn't time in the meeting today for me to ask this:

Where is the open issues list for this draft, so that we can
identify the non-consensus items and drive them to a
resolution?

     Brian

---

From: Dave Thaler <[email-masked]>
Date: Mon, 28 Jul 2008 03:37:38 -0700

I'd suggest also looking at Microsoft's (and any other vendor's)
requirements for IPv6 home routers, since there's already market
incentives for meeting such requirements, similar to the CableLabs
pressure for DSL routers.

Microsoft's are at:
http://www.microsoft.com/whdc/device/network/IPv6_IGD.mspx

-Dave

> Behalf Of Hemant Singh (shemant)
> Sent: Monday, July 14, 2008 8:35 PM
> To: [email-masked]
> Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
> Subject: New (-02) version of IPv6 CPE Router draft is available for
> review
>
> Folks,
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Jul 2008 09:07:32 -0400

Dave,

Thanks for this reference - I do know about the URL but haven't gone
thru the text.  We will totally sift thru Microsoft's requirements and
present a list to this mailer to summarize what we gleaned from it that
is not already included in our draft.  

Hemant

-----Original Message-----
From: Dave Thaler [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 11:38 AM
To: Hemant Singh (shemant); Wes Beebee (wbeebee)
Cc: [email-masked]
Subject: RE: New (-02) version of IPv6 CPE Router draft is available for
review

Microsoft's are at:

-Dave

> Before IETF locks down any new I-D submission today for IETF Dublin, 
> we thought we'd submit this new copy since we had completed new 
> sections for PPP over IPv6 and Softwires to accommodate DSL folks. 
> Other minor review comments have been taken care of as well. Please 
> refer to Change Log for complete change details.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 28 Jul 2008 09:08:46 -0400

Brain,

I and Wes will try and present such a list by sometime tomorrow.

Thanks.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian E Carpenter
Sent: Monday, July 28, 2008 11:34 AM
To: [email-masked]
Cc: Alain Durand
Subject: Open issues list? [Re: New (-02) version of IPv6 CPE Router
draft is available for review]

Where is the open issues list for this draft, so that we can identify
the non-consensus items and drive them to a resolution?

     Brian

---

From: Antonio Querubin <[email-masked]>
Date: Mon, 28 Jul 2008 03:53:56 -1000 (HST)

The -02 draft states:

'Querier Election rules as described in section 7.6.2 of [RFC3810] do
    not apply to the CPE Router since the home network has only one
    router.  Therefore, the CPE Router must always act as an MLD querier
    on its LAN interface(s).'

This is not a good assumption considering there's already been discussion 
of cascading these routers.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Jul 2008 03:48:32 -0400

Even in a cascade there is only one CPE Router that directly faces the
SP upstream router.  This is the router that will proxy MLD reports to
the SP.  This will work if the first CPE Router in the cascade (facing
the SP) is configured for lowest IP address (section 3 of RFC4605).

We are working on changing our mcast section in the draft to reference
RFC4605 since Remi pointed to us we were re-inventing MLD proxy when an
RFC existed on the subject.  We need to work out the details for mcast
in the cascade and propose a smallest common denominator for mcast in
the cascade.

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Monday, July 28, 2008 2:54 PM
To: Hemant Singh (shemant); Wes Beebee (wbeebee)
Cc: [email-masked]
Subject: RE: New (-02) version of IPv6 CPE Router draft is available for
review

The -02 draft states:

This is not a good assumption considering there's already been
discussion of cascading these routers.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Jul 2008 04:29:56 -0400

Brian,

I and Wes can recall only two issues that have not reached consensus.  

The big one was Addressing of the CPE Router WAN interface because NTT,
AT&T, a few folks from the DSL Forum were not in complete agreement - I
and Wes are working this one and this is close to closure.  We talked
with NTT yesterday and David Miles who works in the DSL Forum.  We will
send email on this closure sometime today.

Next one is use of ULA for the home network on the LAN interface(s) of
the CPE Router.  What we have in mind ULA lasts on the device till the
next reboot (ULA will not be renumbered on the device acquiring a GUA)
upon which the same ULA or a different ULA may be generated by the
device.  We are saying the LAN interface(s) will use ULA for the
lifetime of the CPE Router till the router reboots.  Alain is one person
who would like to renumber the ULA on the LAN interface acquiring a GUA.
I didn't see enough justification from him to change the draft in the
ULA regard.  Remi has also replied to Alain's concerns and claimed they
are non-issues.  

Thanks.

Hemant

-----Original Message-----

     Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Jul 2008 05:43:02 -0400

Here is the closure on the Addressing issue for the WAN interface of the
CPE Router.  We could not understand Shin's emails to the mailer, so we
had left it to meeting him at this IETF.  He told us yesterday, in the
NTT IPV6 DSL deployment, the home user uses a Windows PC running routing
code and that PC is a CPE Router for them.  That was the disconnect in
our heads with him - we never thought the PC host he was referring to is
a router. Once we learnt their CPE Router is a Windows PC, we obviously
appreciate his concern if Windows Vista runs the strong host model - the
PC terminates PPP that needs a GUA.  

The following sentences were added to the end of the Unnumbered Model
section to close with Shin and NTT.  

[The unnumbered model is incompatible with the strong host model on the
CPE router. The unnumbered model may be inappropriate for use with
certain broadband deployments where a device that uses the strong host
model can operate as a CPE Router.]  

Further, the first sentence of the Basic IPv6 Provisioning has been
changed as to

[The CPE Router MUST support at least one of two WAN interface models,
one of which will be active on the CPE Router at any given time.]

As for AT&T (Barbara), or David Miles who works in the DSL Forum, or
Mikael A., they can use any one of our Numbered or Unnumbered model for
their purpose.  We need a new version of the draft to show to these
three folks the latest sections for the two model.

Hemant

-----Original Message-----

     Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 29 Jul 2008 10:50:53 -0400

Folks,

Shin reviewed our new text and asked for the word "broadband" be removed
from the text so that the text relates to any deployment where such a
device exists.  So we have removed the word "broadband" from the text.
New text is as follows:

[The unnumbered model is incompatible with the strong host model on the
CPE router.  The unnumbered model may be inappropriate for use with
certain deployments where a device that uses the strong host model can
operate as a CPE Router.]  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)
Sent: Tuesday, July 29, 2008 10:43 AM
To: Brian E Carpenter; [email-masked]
Cc: Alain Durand
Subject: RE: Open issues list? [Re: New (-02) version of IPv6 CPE Router
draft is available for review]

Hemant

-----Original Message-----

     Brian

---

From: [email-masked]
Date: Wed, 30 Jul 2008 00:05:44 -0600

> operate as a CPE Router.]  

I personally disagree with this. I think we need to be more specific rather 
than more general here. We need to specify that this is strictly for fixed 
broadband regardless of the underlying technology (DSL, Cable, ISDN, T1/T3, 
802.16d WiMAX, etc. The rules for mobility based technologies have very 
different requirements and configurations as they are the device and they 
connect directly to the service provider network (no separate router and no 
LAN behind them). 

Eric

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2008 18:50:17 +1200

Thanks for following up on this.

...

> lifetime of the CPE Router till the router reboots.  

What about someone who prefers to have a permanent ULA so that devices
such as printers have permanent addresses? I think that SHOULD be
provided as a user-configurable option.

> Alain is one person

I think there's a philosophical difference behind that. My personal
view of ULAs has always been that their value lies in being provider-
independent and stable, and being always available for intra-site
communications. IMHO they are not temporary addresses for use during
a boot phase or disconnected operation.

Thanks
     Brian

---

From: <[email-masked]>
Date: Wed, 30 Jul 2008 11:13:47 +0300

>> ULA regard.  Remi has also replied to Alain's concerns and claimed 
>> they are non-issues.
>
>I think there's a philosophical difference behind that. My 
>personal view of ULAs has always been that their value lies in 
>being provider- independent and stable, and being always 
>available for intra-site communications. IMHO they are not 
>temporary addresses for use during a boot phase or 
>disconnected operation.

In a use case where WAN connection dynamically changes without (P)MIP
support, should the ULAs be used in LAN, the local connectivity would
not be disrupted by WAN address changes, right? I.e. the ULA would
remain constant, while the global prefix advertised in LAN would
experience sudden renumbering (or perhaps controlled, but still quick,
renumbering could be possible if WAN change is done with help of two
radios (make before break)).

The WAN address change can also happen if WAN connection is for any
reason disrupted and re-establishment does not result in same global
prefix being allocated -> thus immediate renumbering for LAN is
required.

Best regards,

	Teemu

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2008 20:27:57 +1200

> prefix being allocated -> thus immediate renumbering for LAN is

Correct. Sessions open to the outside world will break if that happens,
but not internal sessions using the ULA.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jul 2008 13:24:40 +0100

> next reboot (ULA will not be renumbered on the device acquiring a GUA)

Note that "GUA" isn't a widely understood term...

I'm somewhat concerned that these ULA addresses will do bad stuff to  
existing IPv6 implementations which may or may not use ULA source  
addresses towards public destinations when ULAs have been advertised.

ULAs are only really needed with nested CPEs, because if there's only  
a single CPE you can use link locals. It may also be good to wait a  
short amount of time for global addresses before advertising an ULA  
prefix.

I would suggest some experimentation with this, both in the bad  
effects of ULAs and how workable configuration usin link locals is,  
and only put requirements one way or the other in the document when we  
know more.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jul 2008 13:30:15 +0100

> model can operate as a CPE Router.]

(Can anyone point me to the place where the strong / weak models are  
described? I can never remember what those are, and the names don't  
really help...)

> one of which will be active on the CPE Router at any given time.]

Do you still use a loopback interface with a global address?

---

From: Francois-Xavier Le Bail <[email-masked]>
Date: Wed, 30 Jul 2008 05:57:34 -0700 (PDT)

Strong/weak model : RFC 1122

Francois-Xavier

--- On Wed, 7/30/08, Iljitsch van Beijnum <[email-masked]> wrote:

> From: Iljitsch van Beijnum <[email-masked]>
> Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router draft is available for review]
> To: "Hemant Singh" <[email-masked]>
> Cc: "Brian E Carpenter" <[email-masked]>, [email-masked], "Alain Durand" <[email-masked]>
> Date: Wednesday, July 30, 2008, 8:30 AM
> > [The unnumbered model is incompatible with the strong
> host model on  
> > the

---

From: Pekka Savola <[email-masked]>
Date: Wed, 30 Jul 2008 17:52:36 +0300 (EEST)

On Wed, 30 Jul 2008, Iljitsch van Beijnum wrote:
> ULAs are only really needed with nested CPEs, because if there's only a 
> single CPE you can use link locals.

The first part of the sentence is debatable.  The last part is wrong. 
Many applications just don't work if you use link-local addresses. 
(As a side point, could one CPE even reliably know if there are other 
CPEs?)

FWIW, my belief is that the link-local addresses should never need to 
be used by humans who can't describe the TCP connection establishment 
procedure.  The implication of what you suggest would imply otherwise. 
The pain with multi-interface hosts and making apps deal with scope 
indexes is just too great.  I personally don't care for ULA that much 
myself, but if the alternative is to try to use v6 w/ link-local 
addresses, ULA at least on surface seems like a better approach.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 Jul 2008 18:12:31 +0300

> addresses, ULA at least on surface seems like a better approach.

I am in total agreement here.

-- 
Rémi Denis-Courmont

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 30 Jul 2008 11:29:47 -0400

http://en.wikipedia.org/wiki/Host_model

> Do you still use a loopback interface with a global address?

If the WAN interface has acquired a global address, then a loopback
interface is not needed with a global address to source WAN packets.
However, the Loopback interface has other uses.  Please see the slide
titled "Routing Domains and Address assignments" from our v6ops
presentation and see that the Loopback interface in the picture is being
used with an anycast address for ICMP health check (as per RFC4241).
Also read the latest addressing behavior in the bullets of the same
slide.  You see, a Loopback interface is always available on a router.
One can always use the Loopback interface on the router.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 30 Jul 2008 11:37:43 -0400

Pekka is correct.  It has been discussed in this mailer during
discussion of this draft that link-local's will never work in all cases
for every app.

A CPE Router, say rtr1, can detect another CPE Router, rtr2, cascaded
behind it, if the DHCPv6 server on rt1 receives a DHCPv6 message for
IA_PD.  Since the domain is a home, a rouge router in the home can spoof
such behavior, in which case the detection may be unreliable.

Hemant

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2008 3:53 PM
To: Iljitsch van Beijnum
Cc: Hemant Singh (shemant); Brian E Carpenter; [email-masked]; Alain
Durand
Subject: Re: Open issues list? [Re: New (-02) version of IPv6 CPE Router
draft is available for review]

On Wed, 30 Jul 2008, Iljitsch van Beijnum wrote:
> a single CPE you can use link locals.

FWIW, my belief is that the link-local addresses should never need to be
used by humans who can't describe the TCP connection establishment
procedure.  The implication of what you suggest would imply otherwise. 
The pain with multi-interface hosts and making apps deal with scope
indexes is just too great.  I personally don't care for ULA that much
myself, but if the alternative is to try to use v6 w/ link-local
addresses, ULA at least on surface seems like a better approach.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jul 2008 17:28:33 +0100

On 30 jul 2008, at 15:52, Pekka Savola wrote:

>> ULAs are only really needed with nested CPEs, because if there's  
>> only a single CPE you can use link locals.

> The first part of the sentence is debatable.  The last part is  
> wrong. Many applications just don't work if you use link-local  
> addresses.

It's not impossible to provide an application that will work with link- 
locals. But it shouldn't be too difficult to get the browser vendors  
on board with this once we hammer out how this should work. I do agree  
that link local literarls are unworkable, there would have to be some  
discovery / name resolution in place.

But look at Apple, they've been doing this for some years now wih  
their airport base stations, although they of course use a special  
configuration utility, not a web interface.

> (As a side point, could one CPE even reliably know if there are  
> other CPEs?)

Of course, because it will see their DHCPv6 PD requests.

> indexes is just too great.

Trying to set up two CPEs by connecting them both to different  
interfaces isn't really a good idea...

I would agree if the ULA approach was painfree, but it isn't, users  
may end up having to reboot to get rid of them in order to gain  
reliable IPv6 connectivity.

IF we use ULAs for configuration this has to be very carefully limited  
and controlled to limit these side effects.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jul 2008 17:32:03 +0100

>> http://en.wikipedia.org/wiki/Host_model

Thanks (and the earlier RFC 1122 reference, too).

> However, the Loopback interface has other uses.

But can't these uses be accommodated through the address of a LAN  
interface?

If ISPs end up skimping on address space, using up a /64 for a  
loopback interface would be highly undesirable.

If the LAN interface isn't fully functional, it could still be ok to  
present ISPs with the tradeoff to either forego the functions provided  
by the always reachable address, or require them to provide a WAN  
address.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 30 Jul 2008 12:44:56 -0400

interface?

See my email reply to David Miles who asked for use of a LAN GUA to
source WAN traffic out to the SP.  Yes, it is possible.  BTW, I am also
replying to your other email on our use of GUA.  We have defined the
acronym in the document before using it.  So it's use is very clear.
However, I do appreciate your point.  If there is another better known
acronym used by the community, we will change GUA to that.

Hemant

---

From: james woodyatt <[email-masked]>
Date: Wed, 30 Jul 2008 18:30:27 +0100

> configuration utility, not a web interface.

Apple uses IPv6 link-local transport for a wide variety of user  
application protocols, e.g. AirTunes, iTunes library sharing, iPhoto  
sharing, Time Machine w/ Time Capsule, etc.  The big win for us is  
that we don't have any address realm conflicts with IPv6 link-local  
when hosts are attached as a bastion between their ethernet and Wi-fi  
interfaces.

If it weren't for the utility of IPv6 link-local in preventing address  
realm conflicts, I don't think very many Mac OS X users would today be  
seeing any real-world benefit *at* *all* to having their IPv6 stacks  
enabled.  Indeed, many users are now turning *off* their IPv6 stacks  
altogether to workaround the usual problems caused by it and they're  
finding that the address realm conflict avoidance feature is not  
something they miss all that much.

Still, we remain committed to using IPv6 link-local in this fashion  
for the foreseeable future.  To that extent, we have begun explaining  
to our network interface chipset vendors that hardware support for  
IPv6 checksum calculation/verification and TCP segment offloading is  
one of our considerations when evaluating their products for use in  
our supply chain.

I mention all this to surface the importance of us all getting over  
this bizarre aversion to the idea that link-local scope IPv6 addresses  
are not required for use once there is a global scope prefix  
advertised on the link.  Some of the unique local address arguments we  
are seeing here are red herrings.  Unique local address prefixes are  
only really useful when the CPE LAN is segmented into more than one  
link without any bridges between them, but they still within the same  
administrative domain and routing policy must be used to separate  
them.  These topologies are... rare... in residential networks.  (I  
don't know how rare, but I'd be surprised if they account for more  
than a tenth of a percent of all deployments.)

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jul 2008 18:45:44 +0100

On 30 jul 2008, at 18:30, james woodyatt wrote:

> Unique local address prefixes are only really useful when the CPE  
> LAN is segmented into more than one link without any bridges between  
> them, but they still within the same administrative domain and  
> routing policy must be used to separate them.  These topologies  
> are... rare... in residential networks.  (I don't know how rare, but  
> I'd be surprised if they account for more than a tenth of a percent  
> of all deployments.)

Hm, I've seen the situation where people daisy chain two (or more) NAT  
boxes, for instance, an Airport Extreme doing NAT connecting to an ISP- 
provided ADSL modem doing NAT.

In IPv6 I expect the multi-subnet configuration to become more common  
over time as more and more service providers want to put networked  
devices in the home, and paranoid users will want to split their home  
network into a semi-public part and a private part where they don't  
have to worry about being spied upon by their refrigirator. Especially  
if service providers take it upon themselves to build such a solution  
on behalf of the users, for instance, to make sure the user doesn't  
mess with the IPTV connectivity.

Since unlike with v4 NAT, you can't do multisubnet with v6 without  
help from the other box and the ISP, it's important that we  
accommodate this use case.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 Jul 2008 21:13:52 +0300

Posting as the maintainer of the VLC media player network components...

> when hosts are attached as a bastion between their ethernet and Wi-fi

My experience is that programming with link-local *is* painful. You need to 
carry the scope all over the place. As long as you stick to the sockaddr_in6, 
you're fine. However:

If you ever parse an address from string, boom. There is not even a standard 
to note scope into a numerical IPv6 address.

If you copy the address from a binary-formatted content (packet), boom.

If a DNS lookup yields a link-local address, scope is zero, boom.

Even more stupid, if getnameinfo() returns a link-local scope, it appends the 
non-standard "%eth0" at the end. And if you're not careful when you paste the 
address through a text-protocol, you're unwilling violating the protocol and 
sending non-sense to your peer.

VLC happens to use SAP as its "native" zero-configuration/multicast discovery 
protocol. That embeds addresses (as ASCII string). There is no sane way to 
carry the scope there; it would not make sense anyway. This can be worked 
around by taking the scope of the interface the packet was received from, but 
it *is* painful for the programmer, and tends to break across application 
interface layers. The software I am talking about has had IPv6 support for 
many years, with lots of skilled engineers looking at that over time (as you 
may know, VLC is frequently used in Computer networking R&D depts...). I 
think we finally got link-local mostly right - but what about "normal" 
software?

I am highly reluctant to recommending link-local for normal applications.

-- 
Rémi Denis-Courmont