[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-ngtrans-mech-v2-00.txt
>> i don't think extra rule is needed. when multiple address (mixture of
>> AAAA and A) are returned, client (like SMTP sender) should try to
>> connect to all of them, just like when multiple A records are returned.
>> so it is okay to have IPv4-only SMTP server running on top of
>> IPv4/v6 dual stack node, and advertise both AAAA and A records.
>> the client will try IPv6 connection, fails, and then try IPv4
>> connection.
>I have seens instances where this is a problem.
>Some applications, like Netscape, only do name to address resolution once,
>by fear of ssl connection theft (don't ask me wy they do that).
>So if you contact a web site that is v6 aware, you'll get the v6 addresss.
>Then, if you contact a pop server that is v4 only on the host, the
>connection
>will fail.
then netscape won't work when some of the servers (like 66.218.71.83)
are down when looking at www.yahoo.com. i don't think this is IPv6
problem, but problem in general with multiple address (A/AAAA)
records. i'm not sure where is the best forum to discuss this.
>>>=> This only applies to configured tunnels, and CAN NOT be implemented
>>> for automatic tunnels like 6to4 using relay routers.
>>> I understand this is a sub-section of '4 Configured Tunneling'
>>> but this somehow contradic the text in the security considerations.
>> why not? tunnel ingress box (= 6to4 relay router) should be located
>> at topologically-correct location.
>How do you reconcile this with RFC3068 An Anycast Prefix for 6to4 Relay
>Routers ?
IPv4 (outer) source address of the packet can be different from
the 6to4 anycast prefix (192.88.99.x). RFC3068 doesn't specify
what address should be used as IPv4 source. maybe RFC3068 should say
something about it ("don't use 192.88.99.x as IPv4 source").
RFC3068 section 4.2:
> The 6to4 relay routers that advertise the 6to4 anycast prefix will
> receive packets bound to the 6to4 anycast address. They will relay
> these packets to the IPv6 Internet, as specified in [RFC3056].
>
> Each 6to4 relay router that advertise the 6to4 anycast prefix MUST
> also provide an equivalent IPv4 unicast address. Packets sent to
> that unicast address will follow the same processing path as packets
> sent to the anycast address, i.e., be relayed to the IPv6 Internet.
itojun
; <<>> DiG 9.3.0s20020722 <<>> www.yahoo.com. a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14538
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 10, ADDITIONAL: 0
;; QUESTION SECTION:
;www.yahoo.com. IN A
;; ANSWER SECTION:
www.yahoo.com. 1790 IN CNAME www.yahoo.akadns.net.
www.yahoo.akadns.net. 290 IN A 66.218.71.83
www.yahoo.akadns.net. 290 IN A 66.218.71.84
www.yahoo.akadns.net. 290 IN A 66.218.71.86
www.yahoo.akadns.net. 290 IN A 66.218.71.87
www.yahoo.akadns.net. 290 IN A 66.218.71.89
www.yahoo.akadns.net. 290 IN A 66.218.71.80
www.yahoo.akadns.net. 290 IN A 66.218.71.81
;; AUTHORITY SECTION:
akadns.net. 161825 IN NS ZC.akadns.net.
akadns.net. 161825 IN NS ZD.akadns.net.
akadns.net. 161825 IN NS ZE.akadns.net.
akadns.net. 161825 IN NS ZF.akadns.net.
akadns.net. 161825 IN NS ZG.akadns.net.
akadns.net. 161825 IN NS ZH.akadns.net.
akadns.net. 161825 IN NS USE2.AKAM.net.
akadns.net. 161825 IN NS NS1-93.AKAM.net.
akadns.net. 161825 IN NS NS1-159.AKAM.net.
akadns.net. 161825 IN NS ZA.akadns.net.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(0.0.0.0)
;; WHEN: Wed Sep 18 06:03:18 2002
;; MSG SIZE rcvd: 363