Prefix information includes prefixes other than those associated with
assigned addresses, or the case when the prefix associated with the
address is not on link.
Admittedly, the latter case is less than useful without a default
router. But default router information might come from elsewhere.
Why are we discussing taking a step *backward* in entangling prefix
information with address assignment, when the separation of those two
not-necessarily-related functions is one of the things IPv6 actually
got right? Please step back from saving a couple of bits and think
about the abstractions.
- Ralph
On Aug 17, 2007, at Aug 17, 2007,12:38 PM, Hemant Singh ((shemant))
wrote:
Ralph,
What all information constitutes prefix information? If a node is
DHCPv6
enabled in a RA-absent network, why isn't just the prefix length
enough
for the node to make an on-link determination with? In comparison, a
node that is DHCPv6 enabled in a RA-present network uses prefix length
and L bit together to make an on-link determination.
Thanks.
Hemant
-----Original Message-----
From: Ralph Droms (rdroms)
Sent: Friday, August 17, 2007 12:27 PM
Subject:
References:
<C6FE2907-79C0-4EB2-90AC-
[EMAIL PROTECTED]><7ECEF9368E169544B43882B
[EMAIL PROTECTED]
EXC-02.mgc.mentorg.com><8E296595B6471A4689555D
[EMAIL PROTECTED]><8C324AEB-292B-42E5-
A6B6-4
[EMAIL PROTECTED]><[EMAIL PROTECTED]><F
DB
98139-14EE-4D5F-B96D-
[EMAIL PROTECTED]><[EMAIL PROTECTED]
argle.gargle.HOWL><[EMAIL PROTECTED]><18115.3756.371573.10
32
[EMAIL PROTECTED]><[EMAIL PROTECTED]><m1zm0reu44.wl
%jin
[EMAIL PROTECTED]><[EMAIL PROTECTED]
b-
rtp-20e.amer.cisco.com><[EMAIL PROTECTED]
><
[EMAIL PROTECTED]
rtp-20e.amer.cisco.com><870
6B8AE-001D-4403-
[EMAIL PROTECTED]><B00EDD615E3C5344B0FFCBA910C
[EMAIL PROTECTED]
rtp-20e.amer.cisco.com><39C363776A4E8C4A94691D2BD9D1C9
[EMAIL PROTECTED]
NW-7V2.nw.nos.boeing.com><B00EDD615E3C5344B0FFCBA910CF7E1
[EMAIL PROTECTED]> <18117.50055
[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[EMAIL PROTECTED]>
Cc: "James Carlson" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
"Templin, Fred L" <[EMAIL PROTECTED]>, Iljitsch van Beijnum
<[EMAIL PROTECTED]>, [email protected], JINMEI Tatuya / ????
<[EMAIL PROTECTED]>
Content-Transfer-Encoding: 7bit
From: Ralph Droms <[EMAIL PROTECTED]>
Subject: Re: [dhcwg] Re: prefix length determination for DHCPv6
Date: Fri, 17 Aug 2007 12:27:46 -0400
To: "Hemant Singh (shemant)" <[EMAIL PROTECTED]>
X-Mailer: Apple Mail (2.752.2)
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 17 Aug 2007 16:26:47.0602 (UTC)
FILETIME=[685A1920:01C7E0EB]
Send prefix information, not prefix lengths with assigned addresses.
The little bit of savings in assuming the tie-in between assigned
addresses and on-link prefixes is short-sighted.
- Ralph
On Aug 17, 2007, at Aug 17, 2007,12:23 PM, Hemant Singh (shemant)
wrote:
Thanks, James. I agree with Fred then that a node can try DHCPv6. But
now how does the node get a prefix length? As you are saying, some
manual or static configuration can be used. I certainly don't like
the
host to assume any prefix length in this scenario. Since I am not a
fan of any manual configuration, it does make sense, only for such a
case of absence of an RA, that DHCPv6 provides prefix length. Since
DHCPv6 doesn't know if the network's router will issue RA's or not,
then
DHCPv6
has to provide prefix length all the time.
Then I am for what Iljitsch is saying. If a host see a discrepancy in
prefix lengths from RA and DHCPv6, then host has to decide based on a
union of information.
Hemant
-----Original Message-----
From: James Carlson [mailto:[EMAIL PROTECTED]
Sent: Friday, August 17, 2007 11:49 AM
To: Hemant Singh (shemant)
Cc: Templin, Fred L; Iljitsch van Beijnum; [EMAIL PROTECTED];
[email protected]; JINMEI Tatuya / ????
Subject: RE: [dhcwg] Re: prefix length determination for DHCPv6
Hemant Singh (shemant) writes:
I have not found any information in the ND RFC's nor DHCPv6 RFC that
say a node can initiate DHCPv6 if node doesn't receive any RA. I
need
to see explicit text in some document to accept what you said below.
It does say this. See RFC 2462 section 4:
The next phase of autoconfiguration involves obtaining a Router
Advertisement or determining that no routers are present. If
routers
are present, they will send Router Advertisements that specify
what
sort of autoconfiguration a host should do. If no routers are
present, stateful autoconfiguration should be invoked.
And then more forcefully in 5.5.2:
5.5.2. Absence of Router Advertisements
If a link has no routers, a host MUST attempt to use stateful
autoconfiguration to obtain addresses and other configuration
information. An implementation MAY provide a way to disable the
invocation of stateful autoconfiguration in this case, but the
default SHOULD be enabled. From the perspective of
autoconfiguration, a link has no routers if no Router
Advertisements
are received after having sent a small number of Router
Solicitations
as described in [DISCOVERY].
It's certainly pointless unless you also have access to some static
prefix information, but it's what the documents say to do.
--
James Carlson, Solaris Networking
<[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442
2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442
1677
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dhcwg
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
