RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

["Stark, Barbara" <bs7652@att.com>]

Yes, I was trying to avoid use of (and the access network having to know
routing for) addresses in a different subnet. Before I drop this notion,
let me describe a little better what I need a global address for:

The device that physically includes the CPE router needs to be able to
*initiate* traffic to global addresses on the upstream for the following
purposes:
1. SIP client (SIP registration, SIP invite, etc.); SIP server cannot be
assumed to be "known" to the access network -- it's just another
destination on the Internet
2. various tests, including echo requests, traceroute, http file upload
and download for throughput testing, to destinations on the Internet
3. TR-069 remote procedure calls (running over HTTPS/TCP/IP) for remote
management; the TR-069 server cannot be assumed to be within some sort
of "management domain" of the access network -- it should be thought of
as just another destination on the Internet

In addition, it needs to be able to *receive* incoming traffic:
1. responses to all of the above
2. SIP client receives SIP invites
3. HTTP server can be temporarily enabled (by the customer) to allow the
help desk to troubleshoot by using the device's http UI (of course,
using https); help desk is somewhere out on the Internet, and cannot be
assumed to be able to come in through a controlled part of the access
network.

I don't think these functions are appropriate for something that's
described as a "loopback interface for management purposes". But since I
really don't understand what that loopback interface is, I'd appreciate
others' opinions. Are there other options, or should I just give up and
get a global address from SLAAC/stateful DHCPv6?
Barbara

-----Original Message-----
From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf
Of Ole Troan
Sent: Friday, July 18, 2008 8:49 AM
To: Stark, Barbara
Cc: Hemant Singh (shemant); Antonio Querubin; v6ops@ops.ietf.org
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

> What is the reason for this prohibition?

let me see if I can recall the arguments at the time:

- the model of prefix delegation in 3633 is strictly hierarchical and
you delegate a prefix typically across an administrative boundary
  the upstream link (link between RR and DR) is managed by the DR
- there are already two mechanisms for address assignment, PD is for
prefix delegation not address assignment. if the delegated prefix
  was subnetted also on the upstream, would the RR send RA's for
example?
- the DR will consider the prefix off-link and not use ND for address
resolution, while the RR thinks the prefix is on-link.

what problem are you trying to solve? if you wish to avoid using a
separate /64 for the upstream link, then there is a solution for that
in the draft I believe. (no global address on the upstream link, use
of a loopback interface with an address from the delegated prefix for
management purposes).

cheers,
Ole

>> It does help us if you can point to text in RFC3633 that prohibits
the
> behavior that is being asked by some DSL folks.
>>
>
> section 12.1:
>
>   Upon the receipt of a valid Reply message, for each IA_PD the
>   requesting router assigns a subnet from each of the delegated
>   prefixes to each of the links to which the associated interfaces are
>   attached, with the following exception: the requesting router MUST
>   NOT assign any delegated prefixes or subnets from the delegated
>   prefix(es) to the link through which it received the DHCP message
>   from the delegating router.
>
> /ot
>
> *****
>
> 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. GA623
>
>
>