At Tue, 30 Apr 2002 14:47:20 -0700, Bob Hinden wrote:
>
> The first set of sections (1-8) does not specify the use anycast or
> multicast, only unicast using three well know addresses.
Yes, but
>From the client's point of view, the practical difference between a
well-known unicast address
people have successfully used v4 anycast for long-lived (O(hour) tcp
sessions. it may be ill-advised, but was successful.
if you want to say "don't use for long-lived sessions," that is at
least honest and breaks nothing. but don't disable the major use
of the function as collateral civilian da
>(Now that I mention it, perhaps DHCP relays ought also to be replaced
>by the use of a well-known, site-local anycast address.)
question i have is, can we really depend on availability of multicast
routing infrastructure in a site. there are lots of proposals that
assume
At Tue, 30 Apr 2002 16:36:11 -0700, Bob Hinden wrote:
>
> I think you mentioned in an earlier email about the need for NTP in order
> to use DNSSEC.
More precisely, in order to verify DNSSEC signatures, but yes.
> From the discussion on the list it sounds like the timing requirement for
> DNS
> third, i don't understand why the rule (source address of reply
> has to be equal to the destination of query) is enforced. it may
> have been useful in the past, but with source address spoofing
> getting widely practiced, it provides no protection. the only way
>
>So now we're back to changing the DNS protocol and every IPv6-capable
>DNS client in the world to support triangular wheels.
not really.
first, RFC2181 has particular care about anycast address - see
the last line in section 4.1.
>4.1. UDP Source Address Selection
>
>
>as i have been saying for a year or two. this bit of stupidity makes
>anycast useless for the majority of uses to which it is put today [0].
>i presume it will be ignored, and hence die when this stuff tries to
>go for draft. if not, a buch of v6 use will die [1].
regarding to anycast
Rob,
I think you mentioned in an earlier email about the need for NTP in order
to use DNSSEC.
From the discussion on the list it sounds like the timing requirement for
DNSSEC is for the host to have a clock that is +/- 5 minutes. This could
be implemented with NTP or something else (e.g., a
Hello,
In draft-ietf-ipngwg-scoping-arch-03 Section Mobility, authors say :
"the mobile node MUST NOT try to have a tunnel back into its old zone
for the purposes of attempting such communication".
I think it is quite disappointing to forbid this type of tunnel. If a
MN is listening to a site-
Rob,
>Apologies in advance if this sounds grumpy, it's not intended that
>way, I just haven't had enough coffee yet today. :)
Coffee is a good thing!
To clarify
Sections 1 through 8 is the main body of the proposal (called level 1) and
is what is being considered by the working group. Sect
> So now we're back to changing the DNS protocol and every IPv6-capable
> DNS client in the world to support triangular wheels.
but it's different than v4, so it means we're smarter.
randy
IETF IPng Working Group Mailing List
At Tue, 30 Apr 2002 15:56:12 +0200, Hesham Soliman wrote:
>
> Which boxes does it add? I really don't see any more boxes
> here. Note, I'm not advocating this particular approach (injecting
> routes from the DNS) but I don't agree with your claim above, and I
> think it can work.
This approach w
So now we're back to changing the DNS protocol and every IPv6-capable
DNS client in the world to support triangular wheels.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
Great! I guess I don't have the most recent version of 23.060...
I'm satisfied.
Margaret
At 11:11 AM 4/30/02 , Karim El-Malki (ERA) wrote:
> > Can you site a particular passage in the 3GPP specs that
> > prohibits the GGSN
> > from allocating any addresses (for its own use) within the
>
> Can you site a particular passage in the 3GPP specs that
> prohibits the GGSN
> from allocating any addresses (for its own use) within the
> prefix assigned to each
> PDP context? If so, DupAddrDetectTransmits=0 is fine.
Here is part of the approved change to 23.060 under the
section "D
Rob,
Rob Austein wrote:
>
> At Tue, 30 Apr 2002 08:07:14 -0400, Brian Haberman wrote:
> >
> > Actually that is an incorrect statement. The IPv6 addressing
> > architecture forbids the use of an anycast address as the source
> > address. So, the response back from the anycast member will have
>
The original anycast extensions draft was incorporated into the
MLDv2 draft (draft-vida-mld-v2-02.txt) which is a MAGMA WG
document.
Regards,
Brian
Ralph Droms wrote:
>
> Are the MLD extensions for anycast written up somewhere?
>
> - Ralph
>
> At 03:56 PM 4/30/2002 +0200, Hesham Soliman (ERA)
Hi John,
At 06:41 AM 4/30/02 , [EMAIL PROTECTED] wrote:
>As pointed out, the draft you have edited (draft-ietf-ipv6-3gpp-recommend-02.txt)
>states:
>
> 7.1 Limitations of 3GPP Address Assignment
>
> The current 3GPP address assignment mechanism has the following
> limitations:
>
>
>> Actually that is an incorrect statement. The IPv6 addressing
>> architecture forbids the use of an anycast address as the source
>> address. So, the response back from the anycast member will have
>> one of its unicast addresses as the source address. So, it is
>> similar to your multicast r
>> In the anycast model, you're at the mercy of the system that's
>> maintaining the anycast route: you can't query directly to find out
>> where the DNS server is, you have to wait for the routing system to
>> figure it out, and the routing system doesn't tell you when it change
>> the binding be
Are the MLD extensions for anycast written up somewhere?
- Ralph
At 03:56 PM 4/30/2002 +0200, Hesham Soliman (ERA) wrote:
>
> > >> b) What's the security model by which the router decides
> > whether to
> > >>accept routing updates from the DNS server?
> > >
> > > The same model th
At Tue, 30 Apr 2002 08:07:14 -0400, Brian Haberman wrote:
>
> Actually that is an incorrect statement. The IPv6 addressing
> architecture forbids the use of an anycast address as the source
> address. So, the response back from the anycast member will have
> one of its unicast addresses as the
> >> b) What's the security model by which the router decides
> whether to
> >>accept routing updates from the DNS server?
> >
> > The same model that is used between routers in the network.
>
> Right, so this approach adds a whole new set of boxes that
> can mess up
>
[EMAIL PROTECTED] wrote:
> Hi Margaret,
>
> As pointed out, the draft you have edited (draft-ietf-ipv6-3gpp-recommend-02.txt)
> states:
>
> 7.1 Limitations of 3GPP Address Assignment
>
> The current 3GPP address assignment mechanism has the following
> limitations:
>
> The G
> >>> 1. The DNS can inject a route.
> >> please tell us the rfc or i-d which describes this
> > => I wasn't aware that we need an id to tell
> > us how to run a routing daemon on a node, do we?
>
> i missed routing daemons in the dns protocols
=> Well it's not in the DNS protocols,
>>> 1. The DNS can inject a route.
>> please tell us the rfc or i-d which describes this
> => I wasn't aware that we need an id to tell
> us how to run a routing daemon on a node, do we?
i missed routing daemons in the dns protocols
---
Rob,
Rob Austein wrote:
>
> In the anycast model, you're at the mercy of the system that's
> maintaining the anycast route: you can't query directly to find out
> where the DNS server is, you have to wait for the routing system to
> figure it out, and the routing system doesn't tell you when it
>
> > 1. The DNS can inject a route.
>
> please tell us the rfc or i-d which describes this
=> I wasn't aware that we need an id to tell
us how to run a routing daemon on a node, do we?
But perhaps you're hinting at a bigger issue,
could you please elaborate ?
Hi Margaret,
This discussion is about section:
2.5 RFC2462 - IPv6 Stateless Address Autoconfiguration
IPv6 Stateless Address Autoconfiguration is defined in
[RFC-2462]. This standard is a mandatory part of IPv6.
2.5.1 Stateless Address Autoconfiguration in 3GPP
A 3GPP cellular ho
29 matches
Mail list logo
