> | => It means something like this: > | > | A B > | GGSN ------- Host----<optional>--- whatever you want tp put > | > | GGSNs MUST NOT use the /64 to configure addresses > | on their own interfaces. > > This is exactly why there needs to be an IPv6 over whatever draft > (in the IETF domain). Must of the (DAD related) part of this > discussion has all been noise, as it has all been missing the point.
=> No one disagreed with the need for splitting the I-D into two. But I disagree with your last statement, more below. > In particular: > > | But no DAD is needed on link A. > | > | Makes sense? > > No, this is what is causing the confusion. It isn't that DAD isn't > needed on A, it is that (as you are proposing) doing it there would > simply be wrong, as no address is to be configured there. => No, an address MUST be configured there, yes, only on the host side of the A link. > One never > does DAD on a link other than the one where the address is to be > configured - and your proposal is to have the A link above > be unnumbered, => No, the host configures an address and the GGSN doesn't. This is not _my_ proposal, this is how the 3GPP specs _are_. Have a look at the 3GPP advice draft, including the appendix. > > It is important to get the model right - if you even allow > yourself to > think that what the host is configuring the prefix on the 3GPP link, > then it makes no sense at all to restrict the GGSN from > also configuring > an address on the link - the /64 has plenty of address in > it, => Why doesn't it make sense ? Anyway, there is nothing _I_ can do about that, I'm describing an existing specification. and if it > is configured as a /64 (not two /65's or similar) then it > really applies only > to one link (joining it would be via a bridge). => Have you seen the Multi-link subnet draft? Or do you mean a L3 bridge as the MLSN draft suggests? > > So, what's needed is an I-D that sets out exactly how the > 3GPP link is to > be used, and justifies that. Note that justifying the > "MUST NOT" I quoted > above from your message might not be easy - telling > operators how they're to > be permitted to configure their links is something the IETF > does quite > rarely. In particular, unnumbered links are liked by > some, and hated by > others, so you're going to need to have some very strong > reasons to require > that mode of operation as the only acceptable mode. => I think you should consider it differently: 'we're not proposing a mechanism for 3GPP links, we're describing the host's behaviour based on the existing 3GPP specs'. > > On the other hand, there are still link local addresses to > be assigned on > link A, and there there's no possible justification for the > GGSN not to > assign itself one on the link, nor for the host (or > whatever it turns out to > be, "node" is a better word, many people believe that > "host" excludes > "router") either. Then the question of whether DAD is > required for the > link local addresses becomes relevant, and needs to be specified. => No. The link local address is negotiated before the reception of the RA, so it is impossile to have a collision between the host and GGSN. Just like PPP. Hesham > > kre > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
