Subject: [v6ops] Subject:,Re: 82nd IETF DRAFT Agenda

From: Ray Hunter <[email-masked]>
Date: Mon, 31 Oct 2011 09:45:33 +0100

> Subject:
> Re: [v6ops] 82nd IETF DRAFT Agenda
> From:
> Joel jaeggli <[email-masked]>
> Date:
> Sun, 30 Oct 2011 21:59:23 -0700
>
> To:
> Yu Guanghui <[email-masked]>
> CC:
> [email-masked], [email-masked]
>
> Content-Transfer-Encoding:
> 8bit
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <[email-masked]> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset=GB2312
> Message:
> 3
>
>
> On 10/30/11 21:53 , Yu Guanghui wrote:
>    
>> >  Here is a example:
>> >  
>> >  ping ivi.dlut.edu.cn<- it's a pure IPv6 site behind a stateless translator.
>> >  PING ivi.dlut.edu.cn (58.200.163.1) 56(84) bytes of data.
>> >  64 bytes from 58.200.163.1: icmp_seq=1 ttl=45 time=103 ms
>> >  64 bytes from 58.200.163.1: icmp_seq=2 ttl=45 time=106 ms
>> >  
>> >  but when we trace it:
>> >  
>> >  traceroute ivi.dlut.edu.cn
>> >  traceroute to ivi.dlut.edu.cn (58.200.163.1), 30 hops max, 40 byte packets
>> >    1  202.118.66.1 (202.118.66.1)  0.399 ms  0.459 ms  0.582 ms
>> >    ...
>> >  10  202.112.61.182 (202.112.61.182)  15.579 ms *  15.503 ms<- what happened here? maybe a firewall, router or translator?
>> >  11  * * *
>> >  12  * * *
>> >  ....
>> >  29  * * *
>> >  30  * * *
>>      
>
> right...
>
> and we know that  this guy:
>
> 202.112.61.182
>
> Is the last hop on this side of the event horizon.  just like if there
> were a firewall or a non-stateful icmp filter.
>
>
>    

Exactly.

IMHO this case is actually one of the easier cases of ICMP problems to 
troubleshoot in a modern network, as long as the translator generates an 
ICMP message with a GUA IPv4 source address.

whois 202.112.61.182

and I get an email address: cernet (dash) helpdesk (dash) ip (at) net 
(dot) edu (dot) cn

At least you now know who to contact, and they know exactly which box to 
log into to debug the problem: it's the last hop that isn't showing stars.

And if you find it desirable that the translator should provide 
additional debug information to end users, that can also be handled out 
of band e.g. via SNMP, or a web page hosted on the IPv4 address of the 
translator itself. Many ISP's run such "network looking glass" web 
servers today already. e.g. lg (dot) he (dot) net.

Try both of those debug solutions with a single specially assigned 
source address range that is shared among multiple network managers and 
translators.....

regards,
RayH

---

From: Yu Guanghui <[email-masked]>
Date: Mon, 31 Oct 2011 17:03:26 +0800

在 2011-10-31，下午4:45， Ray Hunter 写道：

> 
>> Subject: Re: [v6ops] 82nd IETF DRAFT Agenda
>> From: Joel jaeggli <[email-masked]>
>> Date: Sun, 30 Oct 2011 21:59:23 -0700
>> To: Yu Guanghui <[email-masked]>
>> CC: [email-masked], [email-masked]
>> Content-Transfer-Encoding: 8bit
>> Precedence: list
>> MIME-Version: 1.0
>> References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
>> In-Reply-To: <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=GB2312
>> Message: 3
>>> > ping ivi.dlut.edu.cn   <- it's a pure IPv6 site behind a stateless translator.
>>> > 10  202.112.61.182 (202.112.61.182)  15.579 ms *  15.503 ms  <- what happened here? maybe a firewall, router or translator?
>>> > 11  * * *
>>> > 12  * * *
>>> > ....
>>> > 29  * * *
>>> > 30  * * *
>>>     
>> 
>> right...
>> 
> IMHO this case is actually one of the easier cases of ICMP problems to troubleshoot in a modern network, as long as the translator generates an ICMP message with a GUA IPv4 source address.
>  
> whois 202.112.61.182
> 
> and I get an email address: cernet (dash) helpdesk (dash) ip (at) net (dot) edu (dot) cn
> 
> At least you now know who to contact, and they know exactly which box to log into to debug the problem: it's the last hop that isn't showing stars. 

Unfortunately , in most cases you are impossible to get help for just a trace result from a unknown ISP. :(

> 
> And if you find it desirable that the translator should provide additional debug information to end users, that can also be handled out of band e.g. via SNMP, or a web page hosted on the IPv4 address of the translator itself. Many ISP's run such "network looking glass" web servers today already. e.g. lg (dot) he (dot) net.
> 
> Try both of those debug solutions with a single specially assigned source address range that is shared among multiple network managers and translators.....
> 
> regards,
> RayH

---

From: Ray Hunter <[email-masked]>
Date: Mon, 31 Oct 2011 11:38:37 +0100

Haven't you just come up with the very best reason for using a GUA IPv4
address for the translator and adding a publicly-accessible out-of-band
"looking glass" web-server to the IPv6/IPv4 translator?

Rather than trying to mess around with ICMP translation that no-one will
trust or understand?

At least you (end user or remote ISP), and the ISP running the
translator, can both locate the translator that you think is causing the
problem, and you are also both looking at the same test tool and the
same test results.

ICMP and traceroute is very unreliable in most production IPv4 networks
for a large number of reasons (MPLS, RFC1918 filters, NAT, Firewalls,
non-stateful packet filters, GRE tunnels, IPv6 transition technologies,
WAN acceleration, ICMP v UDP traceroute) That is unlikely to change.

I really can't remember the last time I saw a traceroute output that
reflected the real hop-by-hop network path, or that did not include stars.

regards,
RayH

Yu Guanghui wrote:
> <snip>

---

From: Yu Guanghui <[email-masked]>
Date: Mon, 31 Oct 2011 19:22:23 +0800

> "looking glass" web-server to the IPv6/IPv4 translator?

Every IPv6 router between the translator and the IPv6 host (also the IPv6 itself) is possible to generate the ICMPv6 messages, a "looking glass" web-server for  the translator couldn't solve this problem.

> WAN acceleration, ICMP v UDP traceroute) That is unlikely to change.

It's true. This draft just provides a possible solution to connect the IPv4/IPv6 ICMP messages (traceroute, pocket to big, etc.)

---

From: Ray Hunter <[email-masked]>
Date: Mon, 31 Oct 2011 13:27:15 +0100

Why not, if the looking-glass server could execute suitable commands on
the translator?

e.g. a traceroute to the remote IPv6 host with a source address either
of the IPv4 GUA translated side of the translator, or the IPv6
untranslated side of the translator, and directly displayed the
resulting ICMPv6 without translation?

What if the looking-glass server on the translator displayed the results
of "debug icmpv6-translation destination <IPv4 address>"?

Now of course it's up to the ISP whether they'd want to give public
access to that sort of command or how they'd secure it.

But why do you think a remote ISP running a translator is any more
likely to accept a trouble ticket from you based on the untraceable /
unverifiable translated ICMP packet that is defined in the draft?

regards,
RayH

---

From: "George, Wes" <[email-masked]>
Date: Mon, 31 Oct 2011 09:17:58 -0400

This long since stopped being about the agenda. Please change the subject line to something more useful to continue the thread about draft-xli-v6ops-ivi-icmp-address

Thanks,

Wes
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Hunter
Sent: Monday, October 31, 2011 4:46 AM
To: Joel Jaeggli; Yu Guanghui
Cc: [email-masked] WG
Subject: [v6ops] Subject:,Re: 82nd IETF DRAFT Agenda

Subject:

From:
Joel jaeggli <[email-masked]><mailto:[email-masked]>

Date:

To:
Yu Guanghui <[email-masked]><mailto:[email-masked]>

CC:
[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Precedence:
list

MIME-Version:
1.0

References:
<[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

In-Reply-To:
<[email-masked]><mailto:[email-masked]>

Message-ID:
<[email-masked]><mailto:[email-masked]>

Content-Type:

Message:
3

right...

202.112.61.182

Exactly.

whois 202.112.61.182

regards,
RayH

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 31 Oct 2011 09:52:56 -0700

On 10/31/11 02:03 , Yu Guanghui wrote:
>>>> > ping ivi.dlut.edu.cn <http://ivi.dlut.edu.cn>   <- it's a pure IPv6 site behind a stateless translator.
>>>> > PING ivi.dlut.edu.cn <http://ivi.dlut.edu.cn> (58.200.163.1) 56(84) bytes of data.
>>>> > traceroute ivi.dlut.edu.cn <http://ivi.dlut.edu.cn>
>>>> > traceroute to ivi.dlut.edu.cn <http://ivi.dlut.edu.cn> (58.200.163.1), 30 hops max, 40 byte packets
>> troubleshoot in a modern network, as long as the translator generates
>> an ICMP message with a GUA IPv4 source address.
>>  
>> whois 202.112.61.182
>>
>> At least you now know who to contact, and they know exactly which box
>> to log into to debug the problem: it's the last hop that isn't showing
>> stars.
> 

That applies regardless of the contents of the trace.

What have I learned by getting packets with a non-useful address (e.g.
one without any intrinsic locator property other than it being an
identifer for ivi)  on them from beyond the event horizon of the translator?

well for one thing...  I learned how many devices there are in the path
that given a source with limited rpf checking I forge a source to that
will then send packets to an intended target of my choice. they might be
invidually rate limited if they have solid control plane acls but
together hey that's a lot of small packets and I can target each one
individually. it's not an amplifier per-see but it certainly does quite
effectively disguise the source.

joel

>> additional debug information to end users, that can also be handled
>> out of band e.g. via SNMP, or a web page hosted on the IPv4 address of
>> the translator itself. Many ISP's run such "network looking glass" web
>> source address range that is shared among multiple network managers
>> and translators.....
>>
>> regards,
>> RayH
>